@preapexis/piexis 0.1.2 → 0.2.2

package/.github/workflows/publish.yml

@@ -0,0 +1,35 @@
+name: Publish npm package
+
+on:
+  push:
+    tags:
+      - "v*"
+
+jobs:
+  publish:
+    runs-on: ubuntu-latest
+
+    permissions:
+      contents: read
+      id-token: write
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - uses: actions/setup-node@v6
+        with:
+          node-version: 24
+          registry-url: https://registry.npmjs.org
+          package-manager-cache: false
+
+      - run: npm ci --ignore-scripts
+      - run: npm run check
+      - run: npm test
+
+      - name: Verify version tag
+        run: |
+          VERSION=$(node -p "require('./package.json').version")
+          TAG=${GITHUB_REF_NAME#v}
+          test "$VERSION" = "$TAG"
+
+      - run: npm publish --access public

package/README.md

@@ -1,15 +1,14 @@
-# Piexis
+# PieXis
 
-Piexis is a Pi package with permission/approval controls, background Git-worktree tasks, prompts, skills, and UI resources. It requires Node.js 22.19+ and a current Pi release (local runtime checks passed with Pi 0.85.1 and 0.87.1 on Linux).
+PieXis is a Pi package with permission/approval controls, background Git-worktree tasks, prompts, skills, and UI resources. It requires Node.js 22.19+ and a current Pi release (local runtime checks passed with Pi 0.85.1 and 0.87.1 on Linux).
 
 > [!WARNING]
-> **Piexis permission controls are not a security boundary.** They help prevent accidental or unapproved agent tool actions; they do **not** provide OS-level sandboxing, filesystem isolation, workspace-only filesystem enforcement, protected-path enforcement, network isolation, or network allowlisting. Run Pi in an appropriate container, VM, sandbox, or restricted user account when executing untrusted code or allowing unattended/high-autonomy agents.
+> **PieXis permission controls are not a security boundary.** They help prevent accidental or unapproved agent tool actions; they do **not** provide OS-level sandboxing, filesystem isolation, workspace-only filesystem enforcement, protected-path enforcement, network isolation, or network allowlisting. Run Pi in an appropriate container, VM, sandbox, or restricted user account when executing untrusted code or allowing unattended/high-autonomy agents.
 
 ## Install and use
 
 ```sh
-npm ci --ignore-scripts
-pi install /absolute/path/to/piexis
+pi install npm:@preapexis/piexis
 ```
 
 Installing the package loads its declared extensions, prompts, skills, and theme. Loading only `extensions/mode.ts` loads only the permission extension. Restart Pi or run `/reload` after installation.
@@ -25,7 +24,7 @@ Use `Alt+M` while the agent is idle to cycle Manual → Accept Edits → Plan
 | **Plan** (`plan`) | Allows project-local ordinary reads, task status/diff inspection/cancellation, and `AskQuestion`; Bash, external/sensitive path-tool reads, task creation/apply/cleanup, and file mutations are blocked. |
 | **Auto** (`auto`) | Directly permits ordinary project-local reads, `edit`, and `write`. Sensitive paths, protected configuration edits, uncertain recursive searches, and malformed or unsupported paths/tools remain denied. Bash outside the harmless-builtin set and eligible narrow session grants, plus remaining known external actions, receive intent-aware model review. Missing authorization, timeout, error, or invalid review denies the action. |
 | **Don't Ask** (`dontAsk`) | Permits only pre-approved reads/questions and harmless Bash builtins; denies other calls without a dialog. Launch-only. |
-| **Bypass Permissions** (`bypassPermissions`) | Skips **Piexis extension-level permission checks**. It does not enter or escape a sandbox, and does not override OS permissions or other extensions. Task scope/confirmation safeguards remain. Launch-only. |
+| **Bypass Permissions** (`bypassPermissions`) | Skips **PieXis extension-level permission checks**. It does not enter or escape a sandbox, and does not override OS permissions or other extensions. Task scope/confirmation safeguards remain. Launch-only. |
 
 Approval UI is fail-closed: calls requiring approval are denied when no permission UI is available. Relative paths resolve against the tool's current working directory, independently of the repository boundary. Both requested and resolved paths are checked; a symlink that resolves outside the project is treated as external, and malformed or unresolvable paths are denied. This is a permission policy, not filesystem sandboxing.
 
@@ -51,7 +50,7 @@ Repository configuration currently selects models only; there are no repository-
 
 ## Configuration
 
-Launching Piexis does not create `.pi/` or project configuration. It uses in-memory defaults when `.pi/permission-modes.json` is absent. Run `/piexis-init` to explicitly create `.pi/settings.json` and `.pi/permission-modes.json`; existing files are never overwritten.
+Launching PieXis does not create `.pi/` or project configuration. It uses in-memory defaults when `.pi/permission-modes.json` is absent. Run `/piexis-init` to explicitly create `.pi/settings.json` and `.pi/permission-modes.json`; existing files are never overwritten.
 
 `permission-modes.json` can select Auto's authenticated classifier and permitted background models:
 
@@ -98,7 +97,7 @@ For reviewed actions, the configured provider receives:
 - Bounded shell parsing results and risk findings; no script or Git configuration contents.
 - For task creation and worker review, the proposed task/brief, selected model, and delegated path/Bash scope, explicitly marked as untrusted action data—not user authorization.
 
-Other than the proposed delegation brief described above, it does **not** receive assistant prose/reasoning, raw tool-output history, worker result summaries, compaction summaries, file contents, edit/write replacement text, environment-variable objects, or Pi authentication credentials. The reviewer has no tool access. User prose, paths, commands, and approval strings can themselves contain secrets: recognition/redaction is best-effort, not a secret-detection guarantee. Do not use Auto when those details must not be disclosed to the selected provider. Recognizably secret-bearing or oversized review payloads are denied locally, without contacting the provider. Piexis does not log review payloads; Pi's normal user-message/session storage still applies.
+Other than the proposed delegation brief described above, it does **not** receive assistant prose/reasoning, raw tool-output history, worker result summaries, compaction summaries, file contents, edit/write replacement text, environment-variable objects, or Pi authentication credentials. The reviewer has no tool access. User prose, paths, commands, and approval strings can themselves contain secrets: recognition/redaction is best-effort, not a secret-detection guarantee. Do not use Auto when those details must not be disclosed to the selected provider. Recognizably secret-bearing or oversized review payloads are denied locally, without contacting the provider. PieXis does not log review payloads; Pi's normal user-message/session storage still applies.
 
 ### Provenance and context limits
 
@@ -116,7 +115,7 @@ Only standalone `pwd`, `pwd -L`, `pwd -P`, `true`, and `false` are automatic Bas
 
 ### Reusable grants
 
-For this first bounded implementation, reusable Bash grants cover only **Git status queries** with a fixed option vocabulary: `--short`/`-s`, `--branch`/`-b`, `--porcelain[=v1|=v2]`, and `--untracked-files=no|normal|all`. Choose either the exact command or that narrow query family. Both are bound to the canonical working directory and a fingerprint of the resolved Git executable's metadata, relevant environment, Git configuration, and Piexis settings/permission configuration. A changed fingerprint requires fresh approval/review. A status query can update Git's optional index caches; it is not part of the automatic read-only builtin set.
+For this first bounded implementation, reusable Bash grants cover only **Git status queries** with a fixed option vocabulary: `--short`/`-s`, `--branch`/`-b`, `--porcelain[=v1|=v2]`, and `--untracked-files=no|normal|all`. Choose either the exact command or that narrow query family. Both are bound to the canonical working directory and a fingerprint of the resolved Git executable's metadata, relevant environment, Git configuration, and PieXis settings/permission configuration. A changed fingerprint requires fresh approval/review. A status query can update Git's optional index caches; it is not part of the automatic read-only builtin set.
 
 Configuration is inspected locally with bounded reads and never sent to the classifier. Unknown Git configuration keys, includes, aliases, hooks/fsmonitor/pager settings, shell startup overrides, script wrappers named Git, and linked worktrees decline reusable grants. Only a small set of inert core/user/remote/branch Git configuration keys is supported. Reuse is currently unavailable on Windows. Ordinary one-time approval or Auto review remains available when reuse is declined. Scripts (`npm test`, `make`, Python, shell scripts, etc.) do **not** receive reusable narrow grants; arbitrary dependency changes cannot therefore silently reuse such a grant. Full script-dependency analysis is not implemented.
 
@@ -133,7 +132,7 @@ Denials include a reason and suggest a genuinely narrower action, clarification,
 
 Once stopped, subsequent tool calls remain blocked except `AskQuestion` (and the deliberately launch-only Bypass mode). A newly delivered provenance-verified user request resets the budget; extension-injected messages and automatic retries do not. Pending sibling approvals cannot grant or execute after the stop. Already executing processes are subject to Pi's normal cancellation, not OS isolation.
 
-Without permission UI, approval-required actions are immediately denied. At the threshold Piexis emits a `permission_blocked` diagnostic on **stderr**, records a count-only session stop entry, and aborts the run without waiting for input or forcing the whole host process to exit. Pi JSON/RPC consumers must inspect the blocked/aborted outcome; this extension does not promise a nonzero JSON-mode exit status.
+Without permission UI, approval-required actions are immediately denied. At the threshold PieXis emits a `permission_blocked` diagnostic on **stderr**, records a count-only session stop entry, and aborts the run without waiting for input or forcing the whole host process to exit. Pi JSON/RPC consumers must inspect the blocked/aborted outcome; this extension does not promise a nonzero JSON-mode exit status.
 
 ## Background tasks
 
@@ -162,13 +161,13 @@ Use `/task status`, `/task review <id>`, `/task diff <id>`, `/task cancel <id>`,
 
 Apply always requires a user dialog showing the **actual changed paths**, sensitive/configuration warnings, and observed command results—even in Auto/Bypass. The patch digest and destination findings are checked again after confirmation, followed by Git apply validation. Worker prose cannot establish successful verification: observations come from post-execution tool records, not claimed test results or blocked tool-start events. Successful command completion is not proof of test coverage; verify again in the parent workspace after application. Repeatedly declined or headless agent-requested apply/cleanup actions use the foreground denial budget.
 
-Cleanup confirms deletion and validates the Piexis ownership marker, temporary directory, Git worktree, and repository before removal. Completed unapplied changes are retained rather than discarded. Headless apply/cleanup is denied. Trusted Pi/Git executables are assumed. These checks are not protection against arbitrary host code or filesystem races.
+Cleanup confirms deletion and validates the PieXis ownership marker, temporary directory, Git worktree, and repository before removal. Completed unapplied changes are retained rather than discarded. Headless apply/cleanup is denied. Trusted Pi/Git executables are assumed. These checks are not protection against arbitrary host code or filesystem races.
 
 Metadata lives at `<agent-dir>/piexis/tasks/<project-hash>.json`, not in the repository. Legacy `.pi/piexis-tasks.json` is imported if user-level state is absent; the source is retained. Interrupted worktrees can be reviewed/cleaned, but authorization, process handles, broker tokens, and user-intent snapshots are never restored from metadata. Fast tests use Git fixtures, mocked worker processes, and mocked reviewers. A separate [runtime suite](tests/runtime/README.md) checks actual Pi RPC/JSON flows, worker processes, and TUI permissions through a pseudo-terminal on Linux, using a deterministic local provider. Live-model accuracy, other platforms, and full visual/terminal compatibility remain unvalidated.
 
 ## Select package resources
 
-Piexis uses Pi's native package resource filtering; it does not add its own plugin manager. Run `pi config` (or `pi config --local` for a trusted project) to enable or disable discovered resources. In settings, the package object can narrow resources declared by this package:
+PieXis uses Pi's native package resource filtering; it does not add its own plugin manager. Run `pi config` (or `pi config --local` for a trusted project) to enable or disable discovered resources. In settings, the package object can narrow resources declared by this package:
 
 ```json
 {

package/package.json

@@ -1,8 +1,12 @@
 {
   "name": "@preapexis/piexis",
-  "version": "0.1.2",
+  "version": "0.2.2",
   "type": "module",
   "description": "Extensions, skills, prompts, and themes for pi",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/VarunGaikwad/piexis"
+  },
   "keywords": [
     "pi-package"
   ],
@@ -20,6 +24,7 @@
     "test:runtime": "node --test tests/runtime/*.test.mjs",
     "check": "tsc --noEmit",
     "eval:permissions": "node eval/permissions.mjs",
+    "release": "node scripts/release.mjs",
     "test:sandbox": "PIEXIS_REQUIRE_SANDBOX=1 node --test tests/mode-sandbox.test.mjs"
   },
   "pi": {

package/scripts/release.mjs

@@ -0,0 +1,32 @@
+import { spawnSync } from "node:child_process";
+import { readFileSync } from "node:fs";
+
+const bump = process.argv[2] ?? "patch";
+if (!["patch", "minor", "major"].includes(bump)) {
+  console.error("Usage: npm run release -- [patch|minor|major]");
+  process.exit(1);
+}
+
+function run(command, args) {
+  const result = spawnSync(command, args, { stdio: "inherit", shell: false });
+  if (result.error) throw result.error;
+  if (result.status !== 0) process.exit(result.status ?? 1);
+}
+
+const status = spawnSync("git", ["status", "--porcelain"], { encoding: "utf8" });
+if (status.status !== 0) process.exit(status.status ?? 1);
+if (status.stdout.trim()) {
+  console.error("Working tree is not clean. Commit or stash changes first.");
+  process.exit(1);
+}
+
+console.log("Running checks...");
+run("npm", ["run", "check"]);
+run("npm", ["test"]);
+
+console.log(`Bumping ${bump} version and creating a Git tag...`);
+run("npm", ["version", bump]);
+
+const packageJson = JSON.parse(readFileSync("package.json", "utf8"));
+console.log(`Pushing v${packageJson.version}; GitHub Actions will publish it.`);
+run("git", ["push", "origin", "HEAD", "--follow-tags"]);

package/.github/workflows/npm-publish.yml

@@ -1,63 +0,0 @@
-name: CI and publish
-
-on:
-  push:
-    branches: [main]
-  pull_request:
-  release:
-    types: [published]
-
-permissions:
-  contents: read
-
-jobs:
-  test:
-    name: Check and test
-    runs-on: ubuntu-24.04
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v5
-
-      - name: Set up Node.js
-        uses: actions/setup-node@v5
-        with:
-          node-version: 24
-          cache: npm
-
-      - name: Install dependencies
-        run: npm ci --ignore-scripts
-
-      - name: Type-check
-        run: npm run check
-
-      - name: Test
-        run: npm test
-
-      - name: Check package contents
-        run: npm pack --dry-run
-
-  publish:
-    name: Publish to npm
-    if: github.event_name == 'release' && github.event.action == 'published'
-    needs: test
-    runs-on: ubuntu-24.04
-    permissions:
-      contents: read
-      id-token: write
-    steps:
-      - name: Checkout release tag
-        uses: actions/checkout@v5
-
-      - name: Set up Node.js
-        uses: actions/setup-node@v5
-        with:
-          node-version: 24
-          registry-url: https://registry.npmjs.org
-
-      - name: Install dependencies
-        run: npm ci --ignore-scripts
-
-      - name: Publish package
-        run: npm publish --provenance
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

package/PERMISSION_MODES_PLAN.md

@@ -1,279 +0,0 @@
-# Piexis Permission Modes Improvement Plan
-
-## Recommended direction
-
-**Make Piexis similar in permission workflow—not a replica of Claude Code’s security architecture.**
-
-Focus on:
-- Fewer interruptions during ordinary coding.
-- Auto decisions grounded in what the user actually requested.
-- Clear approval boundaries for consequential actions.
-- Consistent behavior between foreground and background agents.
-- Understandable denials and permission controls.
-
-**Exclude containers, OS sandboxing, network proxies, and claims of filesystem/network containment.**
-
-This plan records the original baseline and proposed work; the comparison and future-tense descriptions below are historical, not a current behavior reference. Phases 1–4 have been implemented. Phase 5 adds documentation alignment, mode-restoration regression coverage, and a labeled offline classifier evaluation harness. Controlled Linux runtime checks now cover real Pi RPC/JSON flows, worker lifecycle, and TUI permission interactions through a pseudo-terminal (`tests/runtime/README.md`). Live-model evaluation, full visual/terminal compatibility, and cross-platform validation remain open. See `README.md` and `eval/README.md` for current behavior and validation limits.
-
-## Corrections to the comparison
-
-The comparison table is useful as inspiration, but not an implementation specification:
-
-- **Headless denial already exists:** approval-required calls are blocked without permission UI.
-- **Deny-and-continue partly exists:** blocked tool calls already receive reasons. Missing pieces are retry limits and better guidance.
-- **Sensitive-path checks exist**, but they inspect the requested path—not every file a recursive search or shell command might access.
-- **Auto currently ignores all session approvals**, rather than carrying narrow ones forward.
-- **Persistent allow/deny rules and trusted-environment configuration do not exist yet.**
-- **Workers already exist**, with worktrees and an approval broker, but use a separate permission flow and have no Bash.
-- Claude Code also has a `dontAsk` mode; that is not a Piexis-only advantage.
-- Exact claims about Claude’s classifier stages and injection screening need current authoritative verification. We should not make those prerequisites.
-
-## Phase 1 — Make the existing permission foundation consistent
-
-**Do this before expanding Auto.**
-
-### 1. Extract one permission evaluator
-
-Move decision-making out of `extensions/mode.ts` into shared library code.
-
-Inputs should include:
-- Mode.
-- Tool and validated arguments.
-- Actual working directory and workspace boundary.
-- User authorization context.
-- Applicable approvals.
-- Foreground or worker identity.
-
-Return a structured result: **allow, deny, require approval, or require model review**, with a reason/category.
-
-The extension should handle UI and lifecycle; the library should decide policy.
-
-### 2. Fix path-policy limitations
-
-In `lib/path-policy.ts`:
-
-- Resolve relative paths against the **tool’s actual working directory**, then compare against the repository boundary. Currently those two concepts are conflated.
-- Check both requested and resolved paths for sensitive locations.
-- Distinguish reading credentials from modifying execution/security configuration.
-- Cover recursive searches: approving `grep` on the repository root must not imply that every descendant is ordinary.
-- Add categories for credentials, Git internals/hooks, and Pi permission/extension configuration.
-- Avoid treating every example environment file as a real secret; support narrow, explicit exceptions.
-
-If recursive filtering requires wrapping built-in tools, do that explicitly rather than claiming the path check already provides it.
-
-### 3. Protect policy configuration
-
-Ordinary edit permissions should not silently authorize changes to the configuration controlling those permissions.
-
-Repository-provided trust settings must not automatically grant themselves additional authority. Widening permissions needs user confirmation.
-
-**Deliverable:** one documented decision order and consistent path handling, with regression tests.
-
-## Phase 2 — Make Auto genuinely useful for ordinary development
-
-### 1. Pre-approve ordinary local edits
-
-Auto should directly allow:
-- Ordinary project-local reads/searches.
-- Ordinary project-local `edit` and `write`.
-- `AskQuestion`.
-
-Exceptions remain for sensitive paths, policy/configuration changes, malformed requests, and external targets.
-
-This is the highest-value usability improvement.
-
-### 2. Add user-intent context to the classifier
-
-Extend `lib/permission-classifier.ts` beyond tool/path/command.
-
-Include:
-- Current user request.
-- Relevant earlier user constraints from the active branch.
-- Explicit approvals and their scopes.
-- Working directory/workspace.
-- Proposed action and deterministic risk findings.
-
-Exclude:
-- Assistant explanations and reasoning.
-- Raw tool-output history.
-- Worker summaries presented as authorization.
-- Unnecessary file contents and secrets.
-
-**Important:** a message with a `user` role is not automatically proof of human authorization. Pi extensions can inject user messages. Preserve provenance where available and treat ambiguous origins conservatively.
-
-Handle session resume, branching, compaction, and changed instructions without carrying stale authorization forward.
-
-### 3. Introduce a small policy taxonomy
-
-| Category | Proposed Auto behavior |
-|---|---|
-| Ordinary local development | Allow |
-| External filesystem access | Review scope and intent |
-| Destructive changes | Require specific authorization; deny ambiguity |
-| Credential discovery/exposure | Deny automated exploration |
-| Uploads/data egress | Review destination, payload, and intent |
-| Production/shared-system changes | Require explicit target and authorization |
-| Privilege/security changes | Deny unattended escalation |
-| Safeguard bypasses | Require explicit authorization; never infer from “fix it” |
-| Download-and-execute or opaque execution | Conservative review/denial |
-
-Distinguish **using an existing authenticated CLI** from **reading/exporting its credentials**.
-
-### 4. Keep one model reviewer initially
-
-Use:
-
-**Deterministic checks → model review only when needed.**
-
-That already provides a fast path. Do not add a second model until evaluation shows a measurable benefit.
-
-**Deliverable:** Auto feels substantially less intrusive while making better authorization judgments.
-
-## Phase 3 — Improve Bash decisions and permission UX
-
-### Bash analysis
-
-Add a bounded shell analyzer that identifies:
-- Command chains and pipelines.
-- Redirections.
-- Command substitutions.
-- Working-directory changes.
-- Environment assignments and wrappers.
-- Interpreter/script execution.
-- Destructive Git operations.
-- Uploads, deployments, and safeguard-bypass flags.
-
-Use parsing, not only regular expressions. Unsupported syntax should lead to review—not automatic approval.
-
-**Do not equate `npm test`, `make`, or `python script.py` with safety.** Those execute project-controlled code. A command’s name is not its complete effect.
-
-Initially, allow only a small, carefully tested set of simple read-only commands without review. Everything else retains approval/classification.
-
-### Scoped approvals
-
-Add:
-- Exact command + working-directory grants.
-- File/directory grants scoped to operation.
-- Narrow command/subcommand rules.
-- A user-facing `/permissions` command to inspect and revoke grants.
-
-For Auto:
-- Honor eligible narrow approvals after non-overridable checks.
-- Ignore whole-Bash and blanket interpreter/executable grants.
-- Do not reuse an execution approval blindly after the relevant script or policy changes.
-
-Persistent rules can follow later; start with session rules to limit complexity.
-
-### Denial behavior
-
-Provide concise reasons and a legitimate next step:
-- Use a narrower action.
-- Request clarification.
-- Wait for explicit authorization.
-
-Do not suggest switching tools to achieve the same denied effect.
-
-Add configurable repeated-denial limits. Stop the agent’s run when it is stuck; do not automatically switch modes or broaden permissions. Headless runs should report a clear blocked outcome without waiting for dialogs.
-
-**Deliverable:** fewer confusing prompts and no endless denial loops.
-
-## Phase 4 — Bring background tasks into the same permission system
-
-Update `extensions/background-tasks.ts` and `extensions/background-worker.ts`.
-
-### 1. Recognize task tools individually
-
-Auto should understand:
-- Status and cancellation.
-- Diff inspection.
-- Task creation.
-- Applying changes.
-- Destructive cleanup.
-
-Do not allow every custom tool simply because it exists.
-
-Note that `task_diff` currently runs `git add -N` for untracked files: it needs adjustment before being treated as genuinely read-only.
-
-### 2. Give workers bounded delegated authority
-
-Worker authorization should be the intersection of:
-- The user’s authorized task.
-- Parent permission policy.
-- The worker’s delegated scope.
-
-An assistant-written task brief must not expand user authorization.
-
-Use the existing parent broker to evaluate worker actions through the shared policy. Handle mode changes, cancellation, session replacement, and broker failure explicitly.
-
-### 3. Add worker Bash only as an opt-in
-
-Workers can then test/build/debug through the same approval/classifier pipeline.
-
-But call this **permission-controlled command execution**, not sandboxed execution. Worktrees isolate Git changes, not host access.
-
-Keep:
-- No recursive delegation initially.
-- Explicit approval before applying patches.
-- Validated, confirmed cleanup.
-
-### 4. Review returned changes, not just worker prose
-
-Treat worker output as untrusted task data. Inspect the actual patch for sensitive/configuration changes before applying it. Record what verification actually ran.
-
-**Deliverable:** useful workers without building a new orchestration or sandbox platform.
-
-## Phase 5 — Polish, documentation, and evaluation
-
-Preserve the six modes:
-
-| Mode | Target behavior |
-|---|---|
-| Manual | Safe operations directly; approval otherwise |
-| Accept Edits | Also allow ordinary local edits |
-| Plan | Read-only exploration; no implicit transition to execution |
-| Auto | Local coding directly; consequential actions reviewed against intent |
-| Don’t Ask | Only pre-approved actions; no permission dialogs |
-| Bypass | Skip Piexis permission checks, with clear warnings |
-
-Keep mode changes user-controlled and idle-only.
-
-Add tests covering:
-- Nested working directories, symlinks, and recursive searches.
-- Local edits versus sensitive/configuration edits.
-- Shell chains, wrappers, scripts, and uploads.
-- Intent changes, branching, and injected messages.
-- Classifier timeout, cancellation, malformed responses, and unavailable models.
-- Approval revocation and unsafe broad grants.
-- Worker/foreground consistency.
-- Headless denial limits.
-
-Run `npm run check` and relevant tests during implementation. Build a labeled classifier evaluation set as well: mocked unit tests alone cannot measure model decision quality.
-
-## Deliberately deferred
-
-- OS/container/network sandboxing.
-- Network allowlisting presented as enforcement.
-- Full shell/program semantic analysis.
-- Two-model classification.
-- A generic prompt-injection detector marketed as protection.
-- Automatic acceptance of worker changes.
-- Broad domain/org trust configuration before concrete use cases exist.
-
-For injection resistance, prioritize provenance and keeping tool/worker text out of authorization decisions. Optional screening can come later.
-
-## Recommended first release
-
-**Ship Phases 1–3 first.** They provide the biggest Claude-like improvement without ballooning the project. Integrate workers afterward.
-
-## Three decisions before implementation
-
-These recommendations are pending user confirmation.
-
-1. **Auto escalation:** should uncertain/high-impact actions remain denied, or may Auto ask for explicit one-time approval?  
-   **Recommendation:** deny the action first; allow a clear user-controlled approval path in interactive sessions.
-
-2. **Classifier privacy:** are you comfortable sending relevant user requests to the configured classifier provider?  
-   **Recommendation:** yes, with bounded context, clear disclosure, and no raw tool history.
-
-3. **Worker Bash:** should workers eventually run tests/builds without containment?  
-   **Recommendation:** opt-in only, after the shared permission pipeline is implemented.

package/WHAT_YOU_GET.md

@@ -1,153 +0,0 @@
-# What you get with Piexis
-
-Piexis (`@preapexis/piexis`) is a package for the **Pi coding agent**, not a standalone application. It adds control over agent actions, background coding tasks, reusable workflows, and a compact terminal interface.
-
-Installing the full package makes these resources available:
-
-| Included | What it gives you |
-| --- | --- |
-| **5 extensions** | Permission modes, interactive questions, background tasks, file discovery, and a custom terminal UI. |
-| **18 skills** | Task-specific guidance for coding, debugging, reviews, architecture, integrations, and document work. |
-| **3 prompt templates** | `/init`, `/commit`, and `/summary`. |
-| **1 theme** | An optional warm, dark `orange` theme. |
-
-## Permission controls you choose
-
-A new session starts in **Manual** mode unless you select a launch mode or restore a saved session mode. Use **Alt+M** while the agent is idle to cycle through Manual → Accept Edits → Plan → Auto. Auto is skipped when no authenticated classifier is configured.
-
-| Mode | What to expect |
-| --- | --- |
-| **Manual** (`default`) | Ordinary project-local reads and searches are pre-approved. Edits, most Bash commands, and external or sensitive paths require approval. |
-| **Accept Edits** (`acceptEdits`) | Also pre-approves ordinary project-local `edit` and `write` calls. Most Bash commands and external or sensitive paths still require approval. |
-| **Plan** (`plan`) | Read-only exploration and task status/diff inspection/cancellation. Blocks Bash, file changes, task creation/apply/cleanup, and external or sensitive path-tool reads. |
-| **Auto** (`auto`) | Allows ordinary project-local reads and edits, rejects sensitive or unsupported actions, and reviews consequential supported actions against verified user intent. Failed or invalid reviews deny the action. |
-| **Don't Ask** (`dontAsk`) | Allows pre-approved reads/questions, task inspection/cancellation, and tiny harmless Bash builtins; denies other calls without prompting. Launch-only. |
-| **Bypass Permissions** (`bypassPermissions`) | Skips Piexis permission checks. Launch-only; it does not override OS permissions or other extensions. |
-
-Start planning with `/plan <task>`. To select a mode at launch, use `pi --permission-mode <mode>`.
-
-Approval dialogs let you **allow once**, deny, or approve a narrower session scope: a file, directory, ordinary project files for one tool, an eligible exact Git status command, or its narrow query family, bound to the directory and configuration. A clearly labelled whole-tool session approval is also available. Session approvals stay in memory; they are not saved for future sessions. Actions requiring approval are denied when permission UI is unavailable.
-
-**These controls are not a sandbox.** They do not provide OS containment, filesystem isolation, or network restrictions. Use an appropriate container, VM, or restricted account for untrusted or unattended work.
-
-### Optional Auto setup
-
-Run `/piexis-init` to create missing `.pi/settings.json` and `.pi/permission-modes.json` without overwriting existing files. When an authenticated text model is available, initialization selects one for the classifier and background tasks. Simply launching Piexis does not create project configuration.
-
-You can change the classifier in `permission-modes.json` or override it with `PI_PERMISSION_CLASSIFIER=provider/model`. Pi's existing authentication is reused; no credentials are stored in this configuration.
-
-Auto reviews make additional model requests. The classifier receives action details, bounded verified user requests/constraints, and eligible narrow approval scopes. Delegation reviews also include the proposed task brief as untrusted action data. File contents, replacement text, raw tool history, and worker result summaries are excluded. These selected inputs can still contain sensitive information. See [the README](README.md#auto-review-policy-and-privacy) for limits and disclosure details.
-
-## Background tasks without mixing edits into your checkout
-
-Use `/task <work>` to delegate a task to another Pi process. Use task commands to inspect progress; a new ordinary user prompt revokes outstanding worker authorization and cancels active/queued tasks. Up to **two workers** run concurrently; additional tasks queue.
-
-Each worker starts from committed **HEAD** in a separate Git worktree. It receives your task description and any supplied task brief, not the full foreground conversation or your uncommitted changes. Include relevant files, constraints, and acceptance criteria in the task.
-
-| Command | Purpose |
-| --- | --- |
-| `/task <work>` | Start a background task. |
-| `/task status` | List tasks and their states. |
-| `/task review <id>` | Read the worker's result. |
-| `/task diff <id>` | Inspect its actual file changes. |
-| `/task cancel <id>` | Cancel queued or running work. |
-| `/task apply <id>` | Apply a completed task's diff after confirmation. |
-| `/task clean <id>` | Remove a validated task worktree after confirmation; refuses completed, unapplied work. |
-| `/task interrupted` | Find interrupted tasks whose saved work needs inspection. |
-
-The agent also gets `background_task`, `task_status`, `task_diff`, `task_cancel`, `task_apply`, and `task_clean` tools, subject to the active permission policy. Each task tool has its own policy. Auto reviews creation and worker mutations against user intent; apply/cleanup always require explicit confirmation. Plan blocks creation, application, and cleanup.
-
-**Important limits:**
-
-- Git and a repository with a commit are required. Worktrees separate Git changes, **not host filesystem access**.
-- Workers have bounded read/search and edit/write capabilities. Launch with `--background-bash` to opt into permission-controlled command execution, not sandboxing; Bash requires whole-worktree scope.
-- Every worker call uses the parent permission broker; foreground grants are not inherited. Auto reviews worker mutations; Manual prompts for non-pre-approved actions. Missing, denied, or expired authorization blocks the action.
-- Workers do not load your usual skills, prompt templates, or context files. Put essential project guidance in the task brief.
-- Background models use Pi authentication and incur their own model usage. They default to the active model when no background model list is configured; a nonempty `background.models` list restricts model selection; an absent or empty list falls back to the active parent model.
-- Results are not automatically applied or committed. Diff inspection uses temporary Git storage, without staging into the real index. Sensitive/configuration patch bodies are withheld. Apply checks actual paths and reconfirms patch identity; verification observations come from executed tools, not worker claims. Verify again in your checkout.
-- Task metadata and results are saved under Pi's user agent directory. Interrupted worktrees can be inspected or cleaned, but dead worker processes cannot resume.
-
-## Better questions and file discovery
-
-- **`AskQuestion`** lets the agent pause for structured clarification: single-choice, multiple-choice, or free-form answers. Questions are asked sequentially, and you can cancel. It remains permitted in every permission mode but requires the interactive terminal UI.
-- **`glob`** finds files by patterns such as `src/**/*.ts`, respects `.gitignore`, and returns paths relative to the search directory. It wraps Pi's file-finding tool under a familiar name.
-
-## 18 task-focused skills
-
-Skills are instructions, references, and—in some cases—helper scripts, not always-running agents. Pi advertises their descriptions and loads the detailed guidance when relevant. You can explicitly select one with `/skill:<name> <request>`.
-
-### Coding and engineering
-
-| Skill | Use it for |
-| --- | --- |
-| `lean-build` | Implementing a focused feature or ticket with clear scope and acceptance criteria. |
-| `diagnosing-bugs` | Investigating failures and regressions, then making a narrow fix with evidence. |
-| `tdd` | Test-first work using a red–green–refactor workflow. |
-| `safe-refactor` | Restructuring code while preserving behavior. |
-| `migration` | Compatibility-safe schema, data, API, configuration, or dependency transitions. |
-| `code-review` | Reviewing diffs, branches, pull requests, or repositories for actionable issues. |
-| `verify-and-stop` | Checking completed work against acceptance conditions without expanding scope. |
-| `codebase-design` | Designing or auditing architecture, interfaces, ownership, and module boundaries. |
-| `grilling` | Clarifying requirements, pressure-testing plans, and turning ideas into specifications. |
-| `writing-for-agents` | Writing useful skills, `AGENTS.md`, and other agent instructions. |
-
-### Interfaces and integrations
-
-| Skill | Use it for |
-| --- | --- |
-| `frontend-design` | Product web interfaces, visual hierarchy, responsive behavior, and accessibility. |
-| `webapp-testing` | Testing local web apps with Playwright, screenshots, and browser logs. |
-| `mcp-builder` | Building MCP servers in Python or TypeScript to expose external services as tools. |
-| `claude-api` | Anthropic API and SDK integrations, streaming, tools, agents, and troubleshooting. |
-
-### Documents and data
-
-| Skill | Use it for |
-| --- | --- |
-| `docx` | Creating, reading, and editing Word documents and templates. |
-| `pdf` | PDF extraction, creation, merging, splitting, OCR, and forms. |
-| `pptx` | Creating and editing presentations, slides, and templates. |
-| `xlsx` | Spreadsheets, formulas, formatting, charts, and tabular-data cleanup. |
-
-Document and browser workflows may require additional software such as Python packages, Playwright browsers, or LibreOffice. Installing Piexis does **not** provision every skill's external dependencies. Skills also do not bypass permission checks.
-
-## Three reusable prompts
-
-| Prompt | What it asks the agent to do |
-| --- | --- |
-| `/init [focus or constraints]` | Inspect the repository and create or improve concise, evidence-backed `AGENTS.md` guidance. |
-| `/commit` | Review Git changes and return a concise commit message. **It does not create a Git commit.** |
-| `/summary` | Summarize completed work, decisions, open items, next steps, and the user-message count. |
-
-`/init` writes agent guidance; `/piexis-init` initializes Piexis configuration. They are different commands. Prompt templates guide the model and remain subject to your current permission mode.
-
-## A compact terminal workspace
-
-The UI extension adds a Piexis startup header, a project-specific terminal title, and a compact footer showing activity, permission mode, Git branch, model, and context usage.
-
-The bundled **`orange`** theme provides warm accents on dark backgrounds. Select it through **`/settings` → Theme**; installation makes it available but does not automatically change your chosen theme.
-
-## Install and try it
-
-Use a current Pi release; the project README records local runtime checks with Pi **0.85.1 and 0.87.1 on Linux**. The package declares **Node.js 22.19+**; also satisfy your installed Pi version's requirements.
-
-From a local checkout:
-
-```sh
-npm ci --ignore-scripts
-pi install /absolute/path/to/piexis
-```
-
-Restart Pi or run `/reload`. Installing the package loads its declared resources; loading only `extensions/mode.ts` does not give you the rest of the bundle.
-
-Try these in Pi:
-
-```text
-/plan Explain the authentication flow and propose improvements
-/skill:code-review Review the current changes
-/summary
-```
-
-Use **Alt+M** when idle to leave Plan before requesting edits.
-
-**Keep only what you want:** run `pi config` (or `pi config --local`) to enable or disable package resources. You can keep permission controls without the custom UI, or keep coding skills without document workflows. See [the README](README.md#select-package-resources) for resource-filtering examples and configuration details.