tags are how the marketplace is browsed rather than scrolled: a list of them on the left, the plugins that carry one on the right. a closed vocabulary (PLUGIN_TAGS in the platform) because free text becomes homelab, home-lab, Home Lab and selfhosted inside a month, and a filter list of synonyms is worse than no filter at all. declared here rather than curated in the catalogue, so a plugin can say what it is and nobody edits a table when one ships. the marketplace caches it on sync, exactly as it already does for label and summary.
68 lines
3.3 KiB
TypeScript
68 lines
3.3 KiB
TypeScript
import type { PluginManifest } from '@@/plugins/manifest';
|
|
|
|
/**
|
|
* Iris — screenshots of live websites, so agents can SEE rendered pages instead of inferring them.
|
|
*
|
|
* ── What this plugin actually ships ──
|
|
*
|
|
* A CLI (`iris`, github.com/brijr/iris) and the knowledge of how to use it. There is no api/, no web/, no
|
|
* db/: the consumer is an agent's shell, not a screen. The plugin's value is delivered through three
|
|
* channels the platform already carries across an install:
|
|
*
|
|
* sidecar/ builds the binary once with cargo, installs the browser wrapper, then supervises
|
|
* affordances/ the short always-loaded note that tells every agent the tool exists
|
|
* skills/ the full flag reference, loaded on demand
|
|
*
|
|
* ── Why the sidecar builds instead of `release` fetching ──
|
|
*
|
|
* Upstream is a Rust crate. The install pipeline can install packages and fetch release binaries, but it
|
|
* deliberately has no build step — so the one-time `cargo install iris-screenshot` belongs to this
|
|
* plugin's own process, which PM2 starts at the end of the install. First start compiles (minutes);
|
|
* every later start finds the binary and skips. `pm2 logs officer-iris` is where the build narrates.
|
|
*
|
|
* ── Why no browser dependency is declared ──
|
|
*
|
|
* Iris renders through a Chrome-family browser, and Brave, Chromium and Chrome are all fine — the wrapper
|
|
* (`bin/iris-browser`) resolves whichever is present. Declaring one here would be wrong twice over: the
|
|
* package story differs per distro (Ubuntu's apt chromium is a snap stub), and the browser this plugin
|
|
* WANTS is the desktop plugin's, because that is where a person signs in to the sites they ask about.
|
|
* The contract with the desktop plugin is the persistent profile at ~/.config/officer/browser-profile —
|
|
* see README.md.
|
|
*/
|
|
export const manifest: PluginManifest = {
|
|
publisher: 'officerdev',
|
|
version: '0.1.0',
|
|
platform: '>=1.0.0',
|
|
|
|
label: 'Iris',
|
|
summary: 'Website screenshots for agents — eyes on any rendered page, your own Officer included',
|
|
/** agent tooling — eyes on a rendered page. */
|
|
tags: ['Development'],
|
|
icon: 'Camera',
|
|
color: '#8b5cf6',
|
|
|
|
// Empty, and honestly so: the surface is a binary agents run in their own shell, which the platform's
|
|
// permission gate cannot stand in front of. Whose sessions a capture rides is decided by whose Linux
|
|
// user runs it — the wrapper reads $HOME, so the kernel answers, not a grant. An api/ or web/ arriving
|
|
// later brings its key with it.
|
|
permissions: [],
|
|
|
|
osDependencies: [
|
|
{
|
|
// Owner-scoped: cargo is the BUILDER, run once by this sidecar as the owner. Members never invoke
|
|
// it. What they need is the binary it produces — see the iris entry below.
|
|
binary: 'cargo',
|
|
reason:
|
|
'Builds the iris screenshot binary from source, once, on first start. Nothing works without the build. ' +
|
|
'Note: iris needs Rust 1.88+; if your distribution ships older, the sidecar log says exactly what to do.',
|
|
packages: { apt: 'cargo', dnf: 'cargo', pacman: 'rust', brew: 'rust' },
|
|
},
|
|
{
|
|
binary: 'cc',
|
|
reason: 'Links the iris binary during that one-time build.',
|
|
// No brew entry: macOS has cc once the Xcode command-line tools exist, which Homebrew itself requires.
|
|
packages: { apt: 'build-essential', pacman: 'base-devel', dnf: 'gcc' },
|
|
},
|
|
],
|
|
};
|