allye-pi 1.7.1 → 2.0.0

package/docs/install-pi.md

@@ -1,112 +1,42 @@
-# Install Allye for Pi
+# Allye — Pi installation guide
 
-The Pi adapter is a thin native Pi package. It does not copy workflow skills or
-replace Pi's MCP configuration:
+Allye for Pi is the native package `allye-pi`. It:
 
-- `skills/*/SKILL.md` in this repository remains the canonical skill source;
-- the adapter exposes that directory through Pi's `resources_discover` event;
-- Allye context and memory are loaded through the already configured `allye`
-  MCP server via `pi-mcp-adapter`;
-- Herdr is exposed as an optional capability when the Pi session provides `HERDR_ENV=1`.
+- exposes the Bridge skill (`/bridge <mode>`) from the package's `skills/` directory;
+- adds the Allye bootstrap (`bootstrap/allye.md`) to the system prompt;
+- preloads Allye context (`initialize`, `intelligence`) when an in-process MCP bridge is available, and keeps team-scoped work gated until an active team is set (`/allye-team <name|prefix|id>`).
 
-## Official package sources
+It never edits Pi's MCP configuration or reads credentials.
 
-### npm (default production install)
+## Install the package
 
 ```text
-./install.sh install pi
-# equivalent to:
 pi install npm:allye-pi
-
-./install.sh uninstall pi
-# equivalent to:
-pi remove npm:allye-pi
 ```
 
-The installer delegates installation and persistence to Pi's official package
-manager. It never edits `~/.pi/agent/settings.json` manually and the default
-source is always the published npm package. Restart Pi (or run `/reload`) after
-installation.
+From Git (preferably at a tag): `pi install git:github.com/allye-app/allye-plugin`. From a local checkout, for development: `pi install /absolute/path/to/allye-plugin`.
+
+Update with `pi update npm:allye-pi`; remove with `pi remove npm:allye-pi`. Removing the package does not remove MCP configuration or OAuth credentials.
 
-### Git
+## Configure the MCP server
 
-Use Git when you want Pi to install the repository package directly, preferably
-at a tag for reproducibility:
+Recent Pi releases have a native MCP client (verified on Pi 0.99.1). Add the server and sign in:
 
 ```text
-pi install git:github.com/allye-app/allye-plugin
-pi remove git:github.com/allye-app/allye-plugin
+pi mcp add allye --url https://mcp.allye.app/mcp
+pi mcp login allye
+pi mcp list
 ```
 
-This is separate from `./install.sh install pi`, which intentionally remains an
-npm install.
+Do not pass headers, bearer tokens or OAuth client ids: Pi discovers the OAuth endpoints and stores the credential.
 
-### Local checkout (development only)
+On older Pi versions without `pi mcp`, install `pi-mcp-adapter` (`pi install npm:pi-mcp-adapter`), define one server named `allye` (`{"type": "http", "url": "https://mcp.allye.app/mcp"}` under `mcpServers`) in the effective source shown by `/mcp` — for example `~/.pi/agent/mcp.json` or `~/.config/mcp/mcp.json` — then run `/mcp-auth allye` and `/mcp reconnect allye`.
 
-A checkout path is supported, but only through an explicit opt-in so a normal
-production install cannot accidentally load uncommitted code:
+The extension preloads Allye context only when `pi-mcp-adapter` exposes its in-process bridge. Otherwise the bootstrap tells the agent to call `initialize` itself and to ask for a team before team-scoped calls.
 
-```text
-cd /path/to/allye-plugin
-ALLYE_PI_INSTALL_SOURCE=local ./install.sh install pi
-ALLYE_PI_INSTALL_SOURCE=local ./install.sh uninstall pi
-```
+## Team selection
 
-That delegates to `pi install /absolute/path/to/allye-plugin` and
-`pi remove /absolute/path/to/allye-plugin`. Pi manages the package settings and
-runtime dependencies in every case; `skills/*/SKILL.md` remains the single
-canonical skill tree.
-
-The installer deliberately does **not** edit any MCP file. Relative project
-paths are resolved from the installer `PWD`, or from `ALLYE_PI_PROJECT_DIR` when
-installing for a different project. Configure Allye in
-one of the sources supported by `pi-mcp-adapter`: project `.mcp.json` or
-`.pi/mcp.json`, `~/.config/mcp/mcp.json`, `~/.agents/mcp.json`, `~/.agents/mcp/mcp.json`, or
-`~/.pi/agent/mcp.json` (or `$PI_CODING_AGENT_DIR/mcp.json` when that Pi
-override is set). For example, use an
-`allye` server pointing to `https://mcp.allye.app/mcp/<tenant-slug>`.
-Authenticate with `/mcp-auth allye` when required. Existing MCP servers are
-preserved. `./install.sh install pi` reports the first supported source that
-already contains Allye and warns only when none does.
-
-Both npm and Git packages use the root Pi manifest and let Pi install
-`pi-mcp-adapter` as a runtime dependency. The npm tarball contains the adapter
-source, canonical `skills/` directory, and Pi documentation; it is not the full
-plugin checkout and is not the installer input.
-
-## Adaptive toolkit
-
-Pi does not select an executor or orchestrator mode. Allye is available as an
-adaptive toolkit in the current session. Use `/allye-capabilities` to inspect
-Allye/MCP, filesystem, subagent, and Herdr capabilities.
-
-When `HERDR_ENV=1`, the optional `allye_herdr` tool provides bounded `detect`,
-`workspace`, `tab`, `spawn`, `dispatch`, `status`, `mark_intervened`, `wait`,
-`collect`, and ownership-guarded `cleanup` operations. Without it, Pi continues
-locally. Herdr and subagents are capabilities, not prerequisites.
-Tasks are recommended for meaningful, delegated, multi-step, or review-heavy
-work, but an explicitly approved no-task path is supported.
-
-The adapter does not create work items or change statuses automatically. When a
-work item exists, Allye remains the source of truth for scope, decisions, and
-evidence; otherwise the user can proceed with proportional verification.
-
-## Existing Pi startup extension
-
-This package includes its own Allye bootstrap. If a user already has a separate
-`allye-memory-startup.ts`, both can be loaded without changing global files, but
-startup context may be fetched twice. To keep the existing global bootstrap as
-the only startup fetcher, set `ALLYE_PI_NATIVE_BOOTSTRAP=0`; canonical skill
-loading, capability detection, and team-selection guidance remain available.
-
-When `initialize` reports multiple teams without an active team, the adapter does
-not choose one silently and skips team-scoped memory search. If initialization
-fails or its payload is unreadable, the bootstrap is also fail-closed and marks
-Allye as unavailable rather than pretending a team is resolved. It injects the
-team list or connectivity error and instructs the agent to use `allye_team` with
-`team_switch` first. In an interactive session, `/allye-team <name|prefix|id>`
-is available; in headless mode the same instruction is injected for the
-model/user to follow.
+When `initialize` reports several teams and none is active, the extension does not choose one. It tells the agent to ask the user, and `/allye-team <name|prefix|id>` switches the team through the `team` tool (`team_switch`). Set `ALLYE_PI_NATIVE_BOOTSTRAP=0` to skip the context preload (the bootstrap text and the Bridge skill stay available), or `ALLYE_PI_MCP=0` to disable MCP calls from the extension.
 
 ## Local development
 
@@ -116,31 +46,5 @@ From the repository root:
 npm install
 npm run typecheck
 npm run test:pi
-./install.sh status
-jq -e '.pi.extensions and (.pi.skills == ["./skills"])' package.json
+pi -e ./packages/allye-pi/src/index.ts -p "Which Allye tools and Bridge modes are available?"
 ```
-
-The extension is at `packages/allye-pi/src/index.ts`. Test it without changing
-Pi's global settings with:
-
-```text
-pi -e ./packages/allye-pi/src/index.ts -p "Report the available Allye capabilities"
-```
-
-When `allye_herdr dispatch` registers a wait, the wait runs inside the Pi
-process through managed `pi.exec`. On settlement it persists a durable session
-entry, shows a UI notification/message when available, and queues a follow-up
-turn to the current Pi session. That message is evidence only and explicitly
-tells the agent to run `allye_herdr collect` when a managed work item exists and
-inspect Allye `work_children`, Review memories, and Implementation memories
-before declaring completion. Normal completion, timeout, error, and abort are
-distinguished.
-Manual `herdr agent wait` commands started outside this Pi session (for example
-with `nohup` or Bash) do not wake Pi and do not generate this notification.
-
-A real Herdr dispatch still requires `HERDR_ENV=1`, a compatible Herdr session,
-and an existing isolated worktree. Pi records execution IDs plus
-workspace/tab/pane/agent ownership for safe teardown; it never adopts foreign
-panes, stops Herdr, closes panes, merges, pushes, or publishes without explicit
-authorization. Cleanup is only allowed after a settled and collected execution;
-blocked, unknown, timed-out, interrupted, or manually assumed resources remain open.

package/package.json

@@ -1,18 +1,22 @@
 {
   "name": "allye-pi",
-  "version": "1.7.1",
-  "description": "Pi package adapter for the canonical Allye workflow",
+  "version": "2.0.0",
+  "description": "Allye extension for Pi and OMP: the Allye bootstrap, the Bridge skill and the team gate",
   "type": "module",
   "keywords": [
     "pi-package",
+    "omp-plugin",
     "allye",
-    "workflow"
+    "bridge",
+    "mcp"
   ],
   "files": [
     "packages/allye-pi/src/index.ts",
     "packages/allye-pi/tsconfig.json",
     "skills",
+    "bootstrap",
     "docs/install-pi.md",
+    "docs/install-omp.md",
     "LICENSE"
   ],
   "pi": {
@@ -39,7 +43,9 @@
   "scripts": {
     "typecheck": "tsc --noEmit -p packages/allye-pi/tsconfig.json",
     "test:pi": "node --experimental-strip-types --test packages/allye-pi/src/index.test.ts",
-    "test:installer": "bash install/test-pi.sh"
+    "test:installer": "bash install/test-validation.sh && bash install/test-installer.sh",
+    "test:bootstrap": "bash test/test-bootstrap.sh && bash hooks/test-session-start.sh",
+    "test": "npm run test:bootstrap && npm run test:installer && npm run test:pi"
   },
   "repository": {
     "type": "git",