palmier 0.2.3 → 0.2.4

package/README.md

@@ -112,20 +112,15 @@ cat ~/.config/palmier/host.json
 
 ## How It Works
 
-- The host runs as a **systemd user service**, staying alive in the background.
-- The persistent process (`palmier serve`) is an RPC handler. In NATS mode, it derives the method from the NATS subject; in LAN/auto mode, it exposes HTTP endpoints (`POST /rpc/<method>`). The RPC handler (`src/rpc-handler.ts`) is transport-agnostic.
-- **Session tokens** — every RPC request includes a `sessionToken` (in the NATS JSON payload or as an HTTP Bearer token). The host validates the token against `~/.config/palmier/sessions.json` before processing the request. If no sessions exist, validation is skipped.
-- **Task IDs** are generated by the host as UUIDs.
-- All RPC responses (`task.list`, `task.create`, `task.update`) return **flat task objects** — frontmatter fields at the top level, not nested under a `frontmatter` key.
-- **Plan generation is automatic** — `task.create` and `task.update` generate an execution plan and task name by invoking the configured agent CLI. For `task.update`, plans are regenerated only when `user_prompt` or `agent` changes, or when no plan body exists yet.
-- **Run history** — each task run produces a time-stamped result file (`RESULT-<timestamp>.md`) and a task snapshot (`TASK-<timestamp>.md`) in the task directory. A project-level `history.jsonl` file indexes all runs with `{ task_id, result_file }` entries. The `activity.list` RPC reads this index with pagination (`offset`/`limit`, optional `task_id` filter) and enriches each entry with RESULT frontmatter. The `task.result` RPC requires a `result_file` parameter identifying which result to read.
-- The `task.reports` RPC reads one or more report files (each must end with `.md`, plain filenames only) from a task's directory. If the RESULT frontmatter includes a `report_files` field, the PWA shows clickable links in the result dialog that fetch and display each report.
-- Tasks have no separate name field — the `user_prompt` is the primary identifier and display label.
-- **Triggers can be enabled/disabled** via the `triggers_enabled` frontmatter field (default `true`). When disabled, systemd timers are removed; when re-enabled, they are reinstalled. Tasks can still be run manually regardless.
-- Incoming tasks are stored as `TASK.md` files in a local `tasks/` directory.
-- Task execution is abstracted through an **`AgentTool` interface** (`src/agents/agent.ts`). Each task stores an `agent` field (e.g., `"claude"`) that selects which agent implementation constructs the full command line and arguments. The agent's `getTaskRunCommandLine(task)` method builds the appropriate flags (e.g., `--allowedTools` for Claude based on task permissions). The process is spawned without a shell, and stdin is closed to prevent tools from hanging on an open pipe. The spawned process inherits the default physical GUI session environment (`DISPLAY=:0`) so commands that launch graphical applications (e.g., headed browsers) run within the user's desktop session. Task lifecycle status (`start`, `finish`, `abort`, `fail`) is persisted to a `status.json` file in the task directory. Status changes are broadcast on a unified `host-event.<host_id>.<task_id>` subject via NATS pub/sub (when available) and/or pushed through SSE (in LAN/auto mode) by `run.ts` POSTing to the serve process's `/internal/event` endpoint. All events carry an `event_type` field (`"running-state"`, `"confirm-request"`, or `"confirm-resolved"`) with the same payload shape on both transports. Consumers (PWA, Web Server) subscribe to these notifications and fetch full status from the host via the `task.status` RPC.
-- **Task confirmation** — tasks with `requires_confirmation: true` set `pending_confirmation: true` in `status.json` before execution. A `confirm-request` event is published on `host-event` so the Web Server can send push notifications and connected PWA clients show a confirmation dialog. The user confirms or aborts via the PWA, which calls the `task.user_input` RPC on the host. The `serve` process sets `user_input` to the user's response (e.g., `"confirmed"` or `"aborted"`), and `run` watches the file for `user_input` to become defined, then updates `running_state` accordingly.
-- **MCP server** (`palmier mcpserver`) — starts an MCP server over stdio that exposes platform tools to AI agents (e.g., Claude Code). In NATS/auto mode, connects to NATS on startup. Currently exposes a `send-email` tool that relays email requests to the Web Server via NATS (`host.<host_id>.email.send`).
+- The host runs as a **systemd user service**, staying alive in the background via `palmier serve`.
+- **Paired devices** communicate with the host via NATS (cloud-routed) and/or direct HTTP (LAN), depending on the connection mode. Each paired device gets a session token that authenticates all requests.
+- **Tasks** are stored locally as Markdown files in a `tasks/` directory. Each task has a name, prompt, execution plan, and optional triggers (cron schedules or one-time dates).
+- **Plan generation** is automatic — when you create or update a task, the host invokes your chosen agent CLI to generate an execution plan and name.
+- **Triggers** are backed by systemd timers. You can enable/disable them without deleting the task, and any task can still be run manually at any time.
+- **Task confirmation** — tasks can optionally require your approval before running. You'll get a push notification (NATS mode) or a prompt in the PWA to confirm or abort.
+- **Run history** — each run produces a timestamped result file. You can view results and reports from the PWA.
+- **Real-time updates** — task status changes (started, finished, failed) are pushed to connected PWA clients via NATS pub/sub or SSE.
+- **MCP server** (`palmier mcpserver`) exposes platform tools (e.g., `send-email`) to AI agents like Claude Code over stdio.
 
 ## Project Structure
 

package/dist/commands/pair.js

@@ -92,9 +92,9 @@ export async function pairCommand() {
         const sc = StringCodec();
         const subject = `pair.${code}`;
         const sub = nc.subscribe(subject, { max: 1 });
-        cleanups.push(async () => {
+        cleanups.push(() => {
             sub.unsubscribe();
-            await nc.drain();
+            nc.close();
         });
         (async () => {
             for await (const msg of sub) {
@@ -141,7 +141,7 @@ export async function pairCommand() {
     }
     if (!paired) {
         console.log("Code expired. Run `palmier pair` to try again.");
-        process.exit(1);
     }
+    process.exit(paired ? 0 : 1);
 }
 //# sourceMappingURL=pair.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "palmier",
-  "version": "0.2.3",
+  "version": "0.2.4",
   "description": "Palmier host CLI - provisions, executes tasks, and serves NATS RPC",
   "license": "ISC",
   "author": "Hongxu Cai",

package/src/commands/pair.ts

@@ -115,9 +115,9 @@ export async function pairCommand(): Promise<void> {
     const subject = `pair.${code}`;
     const sub = nc.subscribe(subject, { max: 1 });
 
-    cleanups.push(async () => {
+    cleanups.push(() => {
       sub.unsubscribe();
-      await nc.drain();
+      nc.close();
     });
 
     (async () => {
@@ -167,6 +167,7 @@ export async function pairCommand(): Promise<void> {
 
   if (!paired) {
     console.log("Code expired. Run `palmier pair` to try again.");
-    process.exit(1);
   }
+
+  process.exit(paired ? 0 : 1);
 }