mirror of
https://github.com/getpaseo/paseo.git
synced 2026-10-24 10:12:44 +00:00
* refactor(usage): remove agent-to-usage wiring
* feat(plugins): screens, sidebar header and footer items
Plugins register screens with addScreen and contribute component-based
sidebar items with addSidebarHeaderItem and addSidebarFooterItem. Items get
currentScreen, openScreen and openPopover, and render the SidebarRow and
SidebarButton kit. The footer shares the header's ordering model through the
new sidebarFooterItems preference, and Settings > Sidebar gains a Footer card.
addSurface, openSurface and addSidebarItem stay as aliases with their
settings keys and routes.
* refactor(plugins): share resolvePluginPlatform and keep header remembered-host key
Consolidate the five resolvePlatform copies into plugins/platform.ts.
Header sidebar items keep the <pluginId>/sidebar/<id> remembered-host key
so existing users keep their remembered host; footer items use
<pluginId>/sidebar-footer/<id>.
* feat(usage): global usage summary, pins and used/remaining display
- Device-local usage preferences (displayAs, pinned windows) in app settings.
- Sidebar footer usage summary: pinned windows in pin order, one per account;
opens the expanded view as a popover on desktop and a sheet on compact.
- Pin checkboxes on window rows and a used/remaining toggle shared by the
summary, popover, Usage screen and Settings usage section.
- Usage screen shows one host with a selector when several are connected.
- Extract HostSwitcher and the sidebar popover host for reuse.
* fix(usage): render each usage report as its own card
* feat(usage): row pinning, one title row for usage controls, even sidebar footer
- Window rows are the pin toggle (checkbox role, checked state); pinned rows
get a surface2 highlight, unpinned rows an interactionHighlight hover.
- Usage screen, Settings section, popover and sheet put the title left and
the host selector, used/remaining toggle and Refresh right (UsageControls).
PageLayout gains an actions slot; the menu sheet header a trailing slot.
- Sidebar footer rows share 28px height, spacing[1] gaps and one leading rail.
* fix(usage): keep row hover lighter than the pinned highlight
Hovering an unpinned window row shows the pinned surface2 at half opacity on
a separate layer, so it never reads stronger than a pinned row. Pinned rows
do not react to hover.
* fix(app): defer sidebar styles and preserve layout exports in timeline test
* fix(usage): open the Usage screen on desktop, drop the Usage footer icon, match git panel refresh
- Desktop presses on the usage summary open the Usage screen; only compact opens the sheet.
- The Usage footer icon is gone; with nothing pinned the summary renders a plain "Usage" row
in the footer row style. A stored `usage` footer preference is ignored.
- Refresh controls use the Changes panel's icon-only ToolbarButton with RotateCw.
* fix(sidebar): keep the footer icon row fixed; footer items are rows only
The footer's icon row (Hosts, Import session, Help and support, Settings) is back to main's
fixed implementation: not in Settings, not reorderable, and plugins can't add to it.
- Footer items are full-width rows between Add project and the icon row: the usage summary
and plugin `addSidebarFooterItem` rows. The Footer card in Settings lists only those rows.
- Stored `sidebarFooterItems` keys for hosts, import, help and usage are ignored.
- `SidebarButton` is removed from the plugin UI kit; a footer item renders `SidebarRow`.
* refactor(usage): call the sidebar footer item Usage
One concept, one word: the footer item is the Usage item, with key `usage`.
- Settings > Sidebar > Footer lists it as "Usage"; its preference key is `usage`.
- `usage/summary-item.tsx` becomes `usage/sidebar-item.tsx` (`UsageSidebarItem`); both states
use testID `sidebar-usage`.
- `usage/summary.ts` becomes `usage/pinned.ts` (`resolvePinnedUsage`, `PinnedUsageWindow`):
it resolves the pinned windows the item shows.
* feat(plugins): screen params, several rows per sidebar item, SidebarSeparator
openScreen takes { screenId, params }; params live in the screen route's
query so reload, history and links keep them. currentScreen carries the
params. A sidebar item may render a fragment or array of rows; a row press
anchors the popover to that row. SidebarSeparator joins the plugin UI kit.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(plugins): any screen param key; trailing presses anchor the row's popover
Screen params go in the query under a param. prefix, so keys like serverId
no longer collide with the route segments Expo Router merges into search
params. A press anywhere inside a SidebarRow, trailing content included,
makes that row the popover anchor.
Co-Authored-By: Claude <noreply@anthropic.com>
* feat(plugins): plugins title their screens
addScreen takes { id, title, Component }. title is a string or a function
of the screen's params; the screen header shows it and follows param
changes. A title function that throws or returns empty falls back to the
screen id. Legacy addSidebarItem screens keep their item's title and icon,
and the addSurface alias titles its screen with the id.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(usage): require discovery and remove unreleased agent resolver
* fix(plugins): restore legacy sidebar rows, share the item runtime, header hint presses its row
- Legacy addSidebarItem rows are their own group kind again: main's row, registered icon in
Settings, /sidebar/<id> route, host remembered per row.
- New-API items follow the host last used on any of the plugin's screens.
- /sidebar/<id> falls back to a same-id screen so pre-migration links resolve.
- params moves to PluginScreenProps; settings screens no longer receive it.
- Sidebar items, buttons and popovers share one runtime per installation, so no empty first frame.
- A header row's hint slot presses the row; labels wrap as on main.
- Skill and docs corrected.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(usage): one host resolver, sheet reuses the screen's controls, name the host
- The Usage row and screen default to the same host.
- The compact sheet carries the screen's controls, host selector included.
- The host selector shows with one host, and unavailable messages name the host.
- The row, sheet title and pinned label use the sidebar.footer.usage translation.
- Window rows read their percent and reset after the pin label.
- Drop the unread per-report cache writes and headline fixture fields.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(plugins): popovers, header buttons and composer pills own their runtime again
Only sidebar item rows use the installation's shared runtime. Popover content
disposes its runtime on unmount, so observations close with the popover.
* fix(plugins): a sidebar item releases its subscriptions when it unmounts
Each mounted sidebar item gets its own API scope over the host's client, created
during render so its first frame has content. The scope closes a microtask after
unmount (StrictMode's remount keeps it), when the item moves to another host, or
when the installation stops. Replaces the installation-wide shared runtime.
* refactor(plugins): one Paseo client per plugin; authors own their subscriptions
usePaseo() in every plugin surface, and client.paseo in setup, is the
installation's client, created with the installation in the registry. Authors
release their subscriptions in their own cleanup; plugin teardown disposes the
client and ends the rest. Nothing is created or disposed per mounted surface:
the per-surface runtimes, their boundaries, and the per-run Command Center and
slash command APIs are gone.
* refactor(plugins): one Paseo client per plugin; authors own their subscriptions
usePaseo() in every plugin surface, and client.paseo in setup, is the
installation's client, created with the installation in the registry. Authors
release their subscriptions in their own cleanup; plugin teardown disposes the
client and ends the rest. Nothing is created or disposed per mounted surface:
the per-surface runtimes, their boundaries, and the per-run Command Center and
slash command APIs are gone.
* fix(usage): show usage from released hosts
Normalize released-host usage responses at the client boundary so existing usage and pins remain available across app and daemon versions. Include account labels in legacy responses for older apps.
* fix(usage): keep the usage capability check out of the public SDK
* test(server): retry transient locks during runtime test cleanup
* test(usage): model hosts without either usage capability
---------
Co-authored-by: Claude <noreply@anthropic.com>
306 lines
12 KiB
Markdown
306 lines
12 KiB
Markdown
---
|
|
title: Plugin quickstart
|
|
description: Build, install, share, and update a trusted Paseo plugin.
|
|
nav: Quickstart
|
|
order: 44
|
|
category: Plugins
|
|
---
|
|
|
|
# Plugin quickstart
|
|
|
|
A plugin is a TypeScript project installed into one Paseo daemon. It can add
|
|
[screens and sidebar items](/docs/plugins/reference#screens-and-sidebar-items),
|
|
[workspace panels](/docs/plugins/reference#workspace-panels),
|
|
[Command Center items](/docs/plugins/reference#command-center-items),
|
|
[slash commands](/docs/plugins/reference#slash-commands),
|
|
[composer pills](/docs/plugins/reference#composer-pills),
|
|
[timeline items](/docs/plugins/reference#timeline-items),
|
|
[themes](/docs/plugins/reference#contribute-a-theme),
|
|
[attachment sources](/docs/plugins/reference#add-a-composer-attachment-source), and
|
|
[daemon-side RPCs](/docs/plugins/reference#add-plugin-specific-backend-behavior). It can also
|
|
[connect a coding agent as a provider](/docs/plugins/providers). Client
|
|
contributions run on every Paseo client connected to that daemon, including mobile.
|
|
|
|
This guide scaffolds a plugin, runs it, and adds a workspace panel to it.
|
|
|
|
## Create a plugin
|
|
|
|
Use an absolute path on the daemon machine:
|
|
|
|
```bash
|
|
paseo plugin init /absolute/path/to/workspace-plugin
|
|
cd /absolute/path/to/workspace-plugin
|
|
npm install
|
|
```
|
|
|
|
`init` writes a strict TypeScript project and does not run the package manager. `npm install` adds
|
|
development dependencies for typechecking and tests only; Paseo supplies the plugin SDK, React,
|
|
React Native, TanStack Query, and Zod at runtime.
|
|
|
|
The scaffold is a working plugin: a screen, opened from the sidebar, with a button that asks the daemon for a
|
|
greeting through an RPC.
|
|
|
|
```text
|
|
workspace-plugin/
|
|
paseo-plugin.json # plugin ID and supported Paseo versions
|
|
index.client.tsx # runs in the Paseo app
|
|
index.server.ts # runs in a daemon subprocess
|
|
client/greeting.tsx # the screen component
|
|
client/web.ts # the only file allowed to touch browser APIs
|
|
server/greeting.ts # the RPC handler
|
|
shared/greeting.ts # the RPC contract, imported by both
|
|
package.json
|
|
tsconfig.json
|
|
```
|
|
|
|
Each entry default-exports one function that registers contributions and returns a cleanup
|
|
function. `index.client.tsx` registers the screen and the sidebar item that opens it:
|
|
|
|
```tsx
|
|
import type { PluginClientContext, PluginSidebarItemProps } from "@getpaseo/plugin/client";
|
|
import { SidebarRow } from "@getpaseo/plugin/client/ui";
|
|
import { GreetingScreen } from "./client/greeting";
|
|
|
|
function GreetingItem({ currentScreen, openScreen }: PluginSidebarItemProps) {
|
|
return (
|
|
<SidebarRow
|
|
icon="MessageCircle"
|
|
active={currentScreen?.screenId === "greeting"}
|
|
onPress={() => openScreen({ screenId: "greeting" })}
|
|
/>
|
|
);
|
|
}
|
|
|
|
export default function contribute(client: PluginClientContext) {
|
|
client.addScreen({ id: "greeting", title: "Greeting", Component: GreetingScreen });
|
|
client.addSidebarHeaderItem({ id: "greeting", title: "Greeting", Component: GreetingItem });
|
|
return () => {};
|
|
}
|
|
```
|
|
|
|
`index.server.ts` registers the handler for the contract in `shared/greeting.ts`:
|
|
|
|
```ts
|
|
import type { PluginServerContext } from "@getpaseo/plugin/server";
|
|
import { createGreeting } from "./server/greeting";
|
|
import { greetingRpc } from "./shared/greeting";
|
|
|
|
export default function contribute(server: PluginServerContext) {
|
|
server.handle(greetingRpc, createGreeting);
|
|
return () => {};
|
|
}
|
|
```
|
|
|
|
The directory is the boundary. Code under `client/` compiles only into the app bundle, code under
|
|
`server/` only into the daemon bundle, and `shared/` into both. Importing across that line, adding
|
|
a code file at the root, or importing a `node:` module from client code is a compile error. A
|
|
plugin with no daemon-side work can omit `index.server.ts`; a plugin with no UI can omit
|
|
`index.client.tsx`.
|
|
|
|
Client code runs on phones as well as in browsers. The project typechecks without the DOM library,
|
|
so `document` and `window` are errors outside `client/web.ts`, which shows how to gate a browser
|
|
API behind `Platform.OS` with a native fallback. See
|
|
[Cross-platform rules](/docs/plugins/reference#cross-platform-rules) before writing UI.
|
|
|
|
## Install and try it
|
|
|
|
Plugins are trusted, unsandboxed code: server code and preparation commands run with the daemon
|
|
user's access on the daemon machine, and client code runs inside the Paseo app. Installing a plugin
|
|
means you trust that codebase, its dependencies, and its future updates.
|
|
|
|
Turn on **Enable plugins** under **Settings → Plugins** on the daemon you are installing into. It is
|
|
the global switch for every plugin on that daemon. It is also the root `pluginsEnabled` field in the
|
|
daemon's `config.json`; after editing the file, apply it with `paseo reload --json`. An automated
|
|
tool must read the current value and get your explicit permission before turning it on.
|
|
|
|
Then typecheck and install:
|
|
|
|
```bash
|
|
npm run typecheck
|
|
paseo plugin install /absolute/path/to/workspace-plugin
|
|
paseo plugin ls
|
|
```
|
|
|
|
Or install the directory from the app:
|
|
|
|
1. Open **Settings → Plugins** on the target host.
|
|
2. Paste `/absolute/path/to/workspace-plugin` into **Plugin source**.
|
|
3. Select **Install plugin**. The app uses the plugin ID from `paseo-plugin.json`.
|
|
|
|
The source field also accepts Git repositories, npm packages, and plugin subdirectories. See
|
|
[Plugin sources](/docs/plugins/reference#plugin-sources) for the accepted syntax and resolution
|
|
rules. If the form asks you to update the host, update that host before installing; the existing
|
|
management actions remain available.
|
|
|
|
Each installed plugin row shows its status and description. Use its switch to enable or disable it,
|
|
and open its three-dot menu for settings, logs, reload, and removal.
|
|
|
|
`paseo plugin ls` should report the plugin as `running`. Open Paseo, choose **Greeting** in the
|
|
sidebar, and press **Create greeting**. The message comes back from the daemon subprocess through
|
|
the RPC.
|
|
|
|
If the sidebar item is missing, check that **Enable plugins** is on, the plugin is `running`, and
|
|
the client is viewing the host you installed into. `paseo plugin logs workspace-plugin` shows the
|
|
daemon-side output, including load errors.
|
|
|
|
## Add a workspace panel
|
|
|
|
A workspace panel opens as a tab next to agents, terminals, and files. Create `client/overview.tsx`:
|
|
|
|
```tsx
|
|
import { type PluginWorkspacePanelProps, useWorkspace } from "@getpaseo/plugin/client";
|
|
import { useMemo } from "react";
|
|
import { Text, View } from "react-native";
|
|
|
|
export function WorkspaceOverview({ theme, layout, workspaceId }: PluginWorkspacePanelProps) {
|
|
const workspace = useWorkspace(workspaceId, ({ name, directory }) => ({
|
|
name,
|
|
directory,
|
|
}));
|
|
const styles = useMemo(
|
|
() => ({
|
|
screen: {
|
|
flex: 1,
|
|
padding: layout.compact ? 16 : 24,
|
|
gap: layout.compact ? 8 : 12,
|
|
backgroundColor: theme.colors.surface0,
|
|
},
|
|
title: { color: theme.colors.foreground, fontSize: layout.compact ? 20 : 24 },
|
|
label: { color: theme.colors.foregroundMuted },
|
|
detail: { color: theme.colors.foreground },
|
|
}),
|
|
[theme, layout.compact],
|
|
);
|
|
|
|
return (
|
|
<View style={styles.screen}>
|
|
<Text style={styles.title}>{workspace?.name}</Text>
|
|
<Text style={styles.label}>Directory</Text>
|
|
<Text style={styles.detail}>{workspace?.directory}</Text>
|
|
</View>
|
|
);
|
|
}
|
|
```
|
|
|
|
`useWorkspace` reads the fields the panel renders from the app's cached state, without an RPC and
|
|
without re-rendering when unrelated fields change. Every `Text` takes its color from
|
|
`theme.colors`, and `layout.compact` drives spacing, so the panel works in every Paseo theme and on
|
|
phones. See [Theme and layout](/docs/plugins/reference#theme-and-layout) for the token list.
|
|
|
|
Register the panel and a Command Center item that opens it by adding to `index.client.tsx`:
|
|
|
|
```tsx
|
|
import { WorkspaceOverview } from "./client/overview";
|
|
|
|
// Inside contribute(client), after the existing registrations:
|
|
client.addWorkspacePanel({
|
|
id: "overview",
|
|
title: "Workspace overview",
|
|
icon: "PanelsTopLeft",
|
|
context: "workspace",
|
|
locations: ["workspace", "explorer"],
|
|
Component: WorkspaceOverview,
|
|
});
|
|
client.addCommandCenterItem({
|
|
id: "open-overview",
|
|
title: "Open workspace overview",
|
|
icon: "PanelsTopLeft",
|
|
context: "workspace",
|
|
onSelect({ openPanel }) {
|
|
openPanel("overview");
|
|
},
|
|
});
|
|
```
|
|
|
|
`icon` is a [Lucide](https://lucide.dev/icons/) icon name.
|
|
|
|
## Edit and reload
|
|
|
|
Source changes take effect only when you reload the plugin:
|
|
|
|
```bash
|
|
npm run typecheck
|
|
paseo plugin reload workspace-plugin
|
|
```
|
|
|
|
A reload stops the old plugin, runs its cleanup, compiles the current source, and starts it again.
|
|
A failed reload stays failed and reports its error in `paseo plugin ls`; fix the source and reload
|
|
again.
|
|
|
|
Open a workspace, press **⌘K** on macOS or **Ctrl+K** on Windows and Linux, and choose **Open
|
|
workspace overview**. The panel opens as a workspace tab.
|
|
|
|
## Install a published plugin
|
|
|
|
Install a trusted npm plugin using npm on the daemon host:
|
|
|
|
```bash
|
|
paseo plugin install npm:@acme/paseo-review@1.2.0
|
|
```
|
|
|
|
Or paste the same identifier into **Settings → Plugins → Plugin source** and select **Install
|
|
plugin**. The installed row uses the manifest ID and provides the same enable switch, Logs, Reload,
|
|
and Remove actions as a directory plugin. npm is needed for acquisition; subsequent loading and
|
|
reload use the installed files.
|
|
|
|
See [plugin sources](/docs/plugins/reference#plugin-sources) for identifier syntax. To share your own plugin, follow
|
|
[Publish a plugin](/docs/plugins/publishing).
|
|
|
|
Plugins published in a Git repository install by shorthand or URL:
|
|
|
|
```bash
|
|
paseo plugin add owner/repository
|
|
paseo plugin add https://gitlab.com/group/repository.git
|
|
paseo plugin add owner/monorepo:plugins/workspace
|
|
paseo plugin add owner/repository --ref main
|
|
```
|
|
|
|
Append `:relative/path` when the plugin lives below the repository root. `--ref` selects the initial
|
|
Git content once; omitting it installs the default HEAD. See the [source reference](/docs/plugins/reference#plugin-sources) for exact syntax.
|
|
|
|
```bash
|
|
paseo plugin ls
|
|
paseo plugin update workspace-plugin
|
|
paseo plugin update --all
|
|
```
|
|
|
|
`ls` reports source identity and the current installed revision without contacting the remote.
|
|
`update` shows a proposed npm or Git revision and asks for approval. npm offers a newer latest
|
|
release; Git offers the current default HEAD, regardless of the initial install selector.
|
|
Use `--check` to preview only or `--yes` to approve without a prompt.
|
|
See the [CLI reference](/docs/plugins/reference#cli-reference) for explicit targets and bulk updates.
|
|
|
|
## Read backend logs
|
|
|
|
Daemon-side handlers and cleanup can use normal Node logging:
|
|
|
|
```ts
|
|
console.log("Refreshing issues");
|
|
console.error("Issue refresh failed", error);
|
|
```
|
|
|
|
Read the recent output by opening the plugin's three-dot menu under **Settings → Plugins** and
|
|
selecting **Logs**, or use the CLI:
|
|
|
|
```bash
|
|
paseo plugin logs workspace-plugin
|
|
paseo plugin logs workspace-plugin --json
|
|
```
|
|
|
|
The tail includes `[paseo]` loading, ready, stopping, and stopped entries, plus compilation and load
|
|
failures, and it survives reloads and crashes. Client-side output stays in the app. See
|
|
[Debug backend output](/docs/plugins/reference#debug-backend-output) for retention and what not to
|
|
log.
|
|
|
|
## Next
|
|
|
|
- [Publish a plugin](/docs/plugins/publishing): share through npm, a private registry, or Git.
|
|
- [Build a provider plugin](/docs/plugins/providers): connect an agent directly or through ACP,
|
|
render provider-owned timeline items, test it, and publish it.
|
|
- [Plugin reference](/docs/plugins/reference): every contribution type, its fields, the runtime
|
|
modules, hosts, and the CLI.
|
|
- [Migrate a plugin to runtime entries](/docs/plugins/migration): move a plugin written against the
|
|
single `index.ts` entry, step by step.
|
|
- [TypeScript SDK](/docs/sdk): the workspace, agent, provider, and config API available as `paseo`
|
|
in client and server code.
|