@osolmaz/pi-workflows 0.8.1 → 0.8.2

package/docs/MONITOR.md

@@ -19,13 +19,13 @@ The monitor checks a target, sends one status notification after every accepted
 
 | Field                 | Required | Type    | Default            | Meaning                          |
 | --------------------- | -------- | ------- | ------------------ | -------------------------------- |
-| `task`                | Yes      | string  | None               | Self-contained observation task. |
+| `task`                | Yes      | string  | None               | Self-contained monitor task.     |
 | `everyMinutes`        | No       | integer | `30`               | Minutes between accepted checks. |
 | `stopWhen`            | No       | string  | Explicit user stop | Condition that ends monitoring.  |
 | `maxChecks`           | No       | integer | `1000`             | Run safety limit.                |
 | `checkTimeoutMinutes` | No       | integer | Derived            | Timeout for one agent check.     |
 
-`task` is 1 to 8,000 characters after trimming. It should name the target, stable identifier, source of truth, durable outputs, and observation boundary. It must state any authorized mutations. Monitoring is read-only when the task does not authorize a mutation.
+`task` is 1 to 8,000 characters after trimming. It should name the target, stable identifier, source of truth, durable outputs, authorized routine work, and safety boundary. It must state any authorized mutations. Monitoring is read-only when the task does not authorize a mutation.
 
 `everyMinutes` is from 1 through 1,440. The interval begins after a check report is durably queued. It does not delay the first check.
 
@@ -260,11 +260,11 @@ The monitor skill must disclose a surfaced host limit and must never invent a sm
 
 ## Safety boundaries
 
-Monitoring authorizes observation and scheduled checks. It does not authorize retries, restarts, scaling, deployment, publication, cancellation of the target, or higher spending.
+An observation-only request authorizes only observation and scheduled checks. When the user asks the monitor to keep an objective running or finish it, the monitor skill may record routine, bounded work in `task`, including retries, restarts, pinned task code, tests, configuration repairs, and temporary cleanup. The task must preserve the exact objective and state every mutation boundary.
 
 A progress object is data. It cannot contain a command or grant execution authority. Fixed probes belong in workflow-authored `action` or `shell` nodes.
 
-Paid compute, inference runtime, and other domain policies continue to apply to every check.
+A monitoring request does not create spending approval or a default spending ceiling. Existing approvals can cover paid actions, and the monitor should continue without another prompt while each action stays within them. Paid compute, inference runtime, and other domain policies continue to apply to every check.
 
 ## Validation and acceptance
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@osolmaz/pi-workflows",
-  "version": "0.8.1",
+  "version": "0.8.2",
   "description": "Workflow and controller runtime with a live terminal viewer for the pi coding agent",
   "keywords": [
     "pi-package"

package/skills/monitor/SKILL.md

@@ -8,7 +8,7 @@ compatibility: Requires Pi Workflows and the built-in monitor workflow.
 
 Use the built-in Pi `monitor` workflow as an autopilot for the requested objective. Monitoring is not passive status polling. The agent must maintain nominal operation, repair recoverable failures, resume durable work, and continue until the complete objective is verified or a material blocker makes safe continuation impossible.
 
-A monitor request authorizes routine operational actions that are necessary to preserve and finish the stated objective, subject to the conversation and repository approval boundaries. These actions can include restarting or resuming the same non-paid Job or process, repairing an exact operational configuration or storage-path error, retrying transient infrastructure failures, restoring a verified checkpoint, and replacing a failed physical attempt with the same immutable execution contract. Paid launches, resumes, retries, or replacements require the explicit approval described below. Monitoring does not authorize changing the objective, method, model, data source, production selection, or other consequential contract.
+A monitor request authorizes routine, bounded work needed to preserve and finish the stated objective, subject to the conversation and repository approval boundaries. Apply other skills as safety and operating instructions. Do not turn their normal checks into new approval requests when the monitored objective and an existing approval already cover the action. Monitoring does not authorize changing the objective, method, model, data source, production selection, or other consequential contract.
 
 ## Prepare and start without delay
 
@@ -26,7 +26,7 @@ Do not finish the initiating turn before the workflow start call. If a safe cont
 
 Derive the workflow input from the full conversation:
 
-- `task`: State the complete objective, the exact current target and stable identifiers, authoritative status sources, durable progress and final-output surfaces, approved recovery actions, immutable boundaries, cost and credential rules, and required validation or downstream operations.
+- `task`: State the complete objective, the exact current target and stable identifiers, authoritative status sources, durable progress and final-output surfaces, routine actions authorized by the monitor request, other recorded approvals, immutable boundaries, cost and credential rules, and required validation or downstream operations.
 - `everyMinutes`: Use the user's interval when present. Use `30` when the user gives no interval. The built-in workflow accepts intervals from 1 minute through 24 hours.
 - `stopWhen`: Infer verified completion from the full conversation. Describe completion of the complete objective, not only the end of one physical process. Also name material blockers that require human intervention.
 
@@ -34,11 +34,24 @@ When the conversation gives no clear finish criterion, set `stopWhen` to `Stop o
 
 Do not invent a finite check count. Omit `maxChecks` unless the user explicitly requests one. The workflow host can apply its own safety upper bound. Disclose that bound if it appears.
 
+## Keep routine work moving
+
+While the workflow is active, do routine, bounded work required by the exact objective without asking for another confirmation. This includes:
+
+- downloading, building, and running code pinned by the monitored objective;
+- building and running task containers from a pinned benchmark or repository revision;
+- installing pinned dependencies in the planned isolated environment;
+- running canaries, tests, retries, restarts, and temporary cleanup;
+- repairing configuration or storage-path errors without changing the method; and
+- continuing paid work that already has applicable approval.
+
+Pinned third-party code is part of the objective when the task names its exact repository, revision, lock file, image digest, or benchmark release. Resolve mutable references to immutable revisions when the applicable safety rules require it. Do not ask once per image, package, or task. New unpinned code, unrelated code, or broader privileges remain outside the monitor's authority.
+
 ## Paid infrastructure authority
 
-A monitoring request does not grant spending approval or create a default spending ceiling. Before launching, resuming, retrying, or replacing paid work, load and follow the paid-compute, provider, Job-control, and runtime skills that apply. Present the required estimate and obtain explicit approval when those policies require it.
+A monitoring request does not grant spending approval or create a default spending ceiling. Before launching, resuming, retrying, or replacing paid work, load and follow the paid-compute, provider, Job-control, and runtime skills that apply. Use any applicable approval already recorded in the conversation or repository instructions.
 
-After approval, preserve the exact method, hardware, concurrency, cumulative cost ceiling, and recovery assumptions in the monitor task. Continue only within that approved contract. Stop for a decision before new paid work when there is no applicable approval, when the ceiling would be exceeded, or when evidence invalidates an approved assumption.
+When the paid action remains within the approved method, hardware, concurrency, cumulative cost ceiling, and recovery assumptions, continue without asking again. Stop for a decision before new paid work only when there is no applicable approval, the ceiling would be exceeded, or evidence invalidates an approved assumption.
 
 The monitor may use a credential only when the conversation or repository has already authorized that credential's source, destination, and purpose. It may reuse that authorization for retries and replacement attempts under the same objective. It must not discover unrelated credentials, broaden scopes, copy credentials to a new store, or print secret values.