workpilot 0.35.2__tar.gz → 0.36.1__tar.gz

{workpilot-0.35.2 → workpilot-0.36.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: workpilot
-Version: 0.35.2
+Version: 0.36.1
 Summary: Enterprise AI assistant — internal preview only
 Project-URL: Homepage, https://aka.ms/workpilot
 Project-URL: Documentation, https://gim-home.github.io/WorkPilot/
@@ -24,11 +24,12 @@ Requires-Dist: msal>=1.35.1; sys_platform == 'linux' and platform_machine == 'aa
 Requires-Dist: msal[broker]>=1.35.1; sys_platform != 'linux' or platform_machine != 'aarch64'
 Requires-Dist: playwright>=1.58
 Requires-Dist: prompt-toolkit>=3.0
-Requires-Dist: pydantic-monty==0.0.23
+Requires-Dist: pydantic-monty==1.0.0
 Requires-Dist: pydantic<3,>=2.12
 Requires-Dist: pyjwt[crypto]>=2.8
 Requires-Dist: python-multipart>=0.0.9
 Requires-Dist: pyyaml>=6.0
+Requires-Dist: referencing>=0.36
 Requires-Dist: rich>=14.3
 Requires-Dist: tiktoken>=0.9
 Requires-Dist: typer>=0.24

{workpilot-0.35.2 → workpilot-0.36.1}/docs/agents/bridge-mode.md

@@ -4,6 +4,19 @@
 
 Bridge mode lets you drop out of WorkPilot's own agent loop for a session and talk directly to Claude Code or the GitHub Copilot CLI instead, while keeping the same terminal, channel, and audit trail.
 
+## Switch to a persistent WorkPilot agent
+
+After creating an agent in the local/desktop **Agents** page, use `/bridge research` to
+continue its independent conversation. Use `/bridge off` to return to the main assistant.
+`@research message` is the one-shot equivalent and leaves the current bridge selection
+unchanged, including when another internal or external agent is selected.
+
+Internal agents still execute through WorkPilot's normal tools, skills and approvals.
+The external-CLI permission behavior below applies only to `claude` and `copilot`.
+`/pause`, `/resume`, `/stop` and `/status` control a selected internal agent; prefix them
+with `@name` for a one-shot control, for example `@research /stop`.
+See [Persistent agents](overview.md#persistent-agents).
+
 ## Why use it
 
 Normally, WorkPilot's agent loop reasons about your request and calls tools, including the

{workpilot-0.35.2 → workpilot-0.36.1}/docs/agents/overview.md

@@ -18,6 +18,48 @@ Explain which Agent is handling this task and why.
 ```
 :::
 
+## Persistent agents
+
+For a recurring responsibility, create an agent in **Agents** in the local Web UI or desktop
+app. Give it a calling name, instructions, model, tools, skills, and workspace. Leaving the
+workspace blank assigns a separate working directory. Agent definitions used for delegation
+remain reusable templates; creating a persistent member gives it its own durable identity.
+
+```text
+@research Find the release notes.
+@research Continue with the same sources.
+/bridge research
+/bridge off
+```
+
+`@name` addresses only that message. `/bridge name` switches the current conversation until
+`/bridge off`; a one-shot mention while bridged does not change that selection. These commands
+work through the existing CLI, local Web, and cloud chat channels. Use the local/desktop app
+to manage members; cloud chat does not require a new gateway version.
+
+Each member has its own main session, MEMORY.md, HISTORY.md, and SQLite search index. It
+returns to standby after task completion and associated memory processing, with no periodic
+model calls. Pause finishes the current tool batch first. Stop preserves data; continue in
+chat with `@name /resume`. After a restart, interrupted tasks are not automatically retried:
+send a new message or explicitly continue. Bridge selection itself is not restored.
+The same resume command works in a single invocation: `workpilot run "@research /resume"`.
+
+Open a member to inspect its session, edit or clear its memory, search history, or rebuild
+its history index without using a model. Clear memory keeps history and sessions. Stop active
+work before changing configuration, memory, or indexes. Optional skills are selected by name;
+an empty list selects none. The normal security policy still applies: independent data and
+workspaces are not a process or container isolation boundary.
+
+Viewing memory, history, and sessions reads saved data without initializing the member's
+execution environment. Missing optional skills therefore do not prevent inspecting prior work.
+
+If cleanup fails, the remaining cleanup steps and other members are still attempted. The failed
+member retains its data and reports incomplete cleanup; use **Stop** again to retry.
+
+Automatic team creation, automatic collaboration, and team-shared memory are not part of this
+first version. Scheduled-job and Event management remain with the main assistant.
+See [Bridge mode](bridge-mode.md) and [Local data](../storage/overview.md).
+
 ## Built-in agents
 
 | Agent | Purpose |

workpilot-0.36.1/docs/automation/events.md

@@ -0,0 +1,197 @@
+---
+description: Fixed-code condition checks, explicit fingerprint grants, isolated tests, and separate scheduled tasks.
+workpilot_search:
+  keywords:
+    - Event fixed main context boolean monitor condition automation
+    - expected false fresh check scoped approval isolated test
+    - Events Web approval API key Entra
+---
+
+# Events
+
+> [中文版](../zh-cn/automation/events.md)
+
+An Event checks a condition with fixed Python code, without an agent reasoning on every poll.
+A separate [scheduled task](scheduling.md) decides what to do. The four contracts are
+`EventDefinition`, `EventContext`, `EventRun`, and `EventConditions`; live tool schemas are authoritative.
+
+::: tip Ask WorkPilot
+“Monitor the build every minute and summarize it when complete.”
+“At 9 AM, check afresh and prepare only if the build is still running.”
+:::
+
+## Availability and manual setup
+
+Events default to `events.enabled: false`. An operator must enable it and keep
+`tools.code_mode.enabled` enabled (its default).
+Clocks also require `cron.enabled` and a running scheduler host; manual checks do not require cron.
+Do not silently enable dependencies. See [scheduler setup](scheduling.md#enable-the-scheduler-manually).
+Global defaults are `max_concurrent_checks: 5`, `max_pending_checks: 200`, and
+`history_retention_days: 30` under `events`. Checks are bounded and serialized per Event;
+overload and output truncation are explicit. See the [configuration reference](../configuration/schema.md).
+Nested checks report `blocked` / `overloaded` rather than waiting for busy execution capacity
+or another run of the same Event; ordinary callers can still wait within the pending-check limit.
+
+### Web-host authentication prerequisite
+
+Web chat and Event approval transports must be authenticated through Entra or an effective API key.
+The gateway's existing temporary generated key is valid; a permanently configured key is not required.
+CLI or standalone Cloud use does not itself require Web configuration. See
+[Local gateway authentication](../gateways/local.md#authentication-and-network-exposure).
+
+## From a request to an enabled check
+
+1. Agree on true, false, unknown/error, printed evidence, and a separate task and destination.
+2. Inspect existing definitions/history. Load `tools(name="event-automation", action="skill")`;
+   describe `events`, `cron`, and source tools before using their actual schemas.
+3. Save a disabled draft. Static `validate` checks schema/entrypoint without host calls and reports
+   `type_checked: false`; native type checking happens during execution.
+4. Request explicit human [authorization](#authorization) for that Event ID and fingerprint;
+   saving is not approval.
+5. Run an authorized, isolated `test` when appropriate and inspect its result and real effects.
+6. Enable the authorized revision and verify history; never infer execution from a successful save.
+
+## Author a fixed checker
+
+Use `async def main(context)` for tool calls or `def main(context)` for computation. The runtime
+invokes it in a fresh code-mode sandbox. The checker engine needs no model; tools may use one.
+Read-only queries are recommended, not enforced: other granted tools are eligible. Checkers cannot
+call `agent`, `spawn`, or `run_code`, directly or through `call_tool`. They can inspect cron tasks
+but cannot add, enable, or run them; task actions are separate.
+A tool-free comparison, with `actual` and `expected` supplied in `params`, is:
+
+```python
+def main(context):
+    return context["params"]["actual"] == context["params"]["expected"]
+```
+
+Example disabled `create` payload (not a YAML import file); discover `read_file` first:
+
+```yaml
+id: build-ready
+description: Check whether the build has completed
+enabled: false
+params: {path: build-status.txt}
+pre_trigger: {schedule: 60}
+code: |
+  async def main(context):
+      text = await read_file(path=context["params"]["path"])
+      print(text[:1000])
+      complete = "status=complete" in text
+      running = "status=running" in text
+      if complete == running:
+          raise ValueError("Expected one recognized build status")
+      return complete
+```
+
+`timeout_seconds` defaults to 60. Use optional `expires_at` for bounded monitoring.
+Keep credentials in existing tool configuration, not code, params, or printed details.
+
+Prefer booleans on successful paths. Python truthiness remains compatible, with coercion diagnostics:
+`None` and empty values are false, but the string `"false"` is true. Do not disguise errors as false.
+Errors, blocked, cancelled, interrupted checks, and missing/expired observations have no boolean.
+`print` is bounded supplementary data, separate from the result and diagnostics.
+Run history uses one `source`: `manual`, `time`, or `test`. Test runs never become production
+observations.
+
+Context is a copied snapshot containing `event`, `run`, `params`, `input`, and `last_success`.
+`last_success` is the previous successful production check for this revision, including false,
+or `null`; tests/failures do not replace it. There is no writable `context.state` or mutation
+writeback. Input cannot replace host identity, params, or authority.
+
+## Authorization
+
+Authorization approves an entire fixed Event by **`event_id` + `fingerprint`**, within trusted
+owner/workspace boundaries. The fingerprint is the SHA-256 hash of its executable definition,
+not a credential or proof of approval.
+Event IDs are unique within that owner/workspace, not globally. Other scopes may use the
+same ID with independent definitions, grants, observations and clocks.
+`create`, `get`, and `list` expose the current `fingerprint`. Pass it with `event_id` to `authorize`;
+optional `expires_at` limits the grant. There are no per-tool or per-argument grant rules:
+approval covers the otherwise permitted tool calls made by that fixed Event.
+Executable configuration changes produce a different fingerprint and invalidate approval.
+`update` still takes `changes` and `expected_revision` for edit concurrency; revision is not a
+grant-matching field. Existing tool ceilings, hard denies, E-stop, audit, and postflight remain.
+Description and error-notification edits keep the execution revision, grant, observations and timer;
+they do not interrupt an active check. They remain editable after a one-shot time or expiry has
+passed; these edits do not rearm the check or extend its authorization. New executable settings
+must still satisfy schedule and expiry validation.
+Approval cards show the complete checker and JSON authorization scope: Event ID/fingerprint,
+owner/workspace, executable configuration, and expiry. Review both before
+approving unattended execution; the Security approval queue shows the same checker and scope.
+When they are too large for a Teams card, the card points to the Security approval queue instead.
+
+Inspect the saved Event, use the full fingerprint returned by `get`, wait for the human
+decision, then test:
+
+```python
+events(action="get", event_id="build-ready")
+events(action="authorize", event_id="build-ready",
+       fingerprint="<fingerprint returned by get>")
+events(action="test", event_id="build-ready")
+```
+
+Tests execute granted real tools; inspect earlier effects before repeating them. Nested checks
+inherit isolation: no production observations or task triggering. Production `run` may trigger tasks.
+Checker grants never transfer to actions; those retain ordinary [approvals](../security/approvals.md).
+
+## Combine time and conditions
+
+Event timers poll independently; clocked tasks **check fresh at each tick** rather than using cache.
+Event-only tasks use committed `event.checked` observations without recursive checks. `cron` examples:
+
+```yaml
+name: build-summary
+schedule: event.checked
+event_conditions:
+  mode: all
+  items: [{event_id: build-ready, equals: true, max_age_seconds: 120}]
+event_policy: {mode: enter_match, cooldown_seconds: 300}
+prompt: Summarize the completed build using the attached check details.
+```
+
+```yaml
+name: morning-preparation
+schedule: "0 9 * * *"
+timezone: Asia/Shanghai
+event_conditions:
+  mode: all
+  items: [{event_id: build-ready, equals: false}]
+prompt: Prepare the build follow-up while the build is still running.
+```
+
+`all` requires every match; `any` needs one known match. Unknown is never false.
+`max_age_seconds` bounds observation age and is rechecked before dispatch, including after waiting
+for task capacity. `each_match` dispatches on matching results;
+`enter_match` on entry into a match, including the first known match. Cooldown is not exactly-once delivery.
+One-shot pre-triggers retain their resolved occurrence across restart and consume it atomically
+with check reservation. Unknown started checks are not automatically replayed.
+For absolute `at:` timestamps without an offset, `pre_trigger.timezone` selects the wall-clock
+timezone (local timezone when omitted). An explicit timestamp offset takes precedence;
+relative `at:+seconds` delays are unchanged.
+
+## Handoff and management
+
+Existing cron owns execution, overlap, capacity, and history; no separate task queue or replay exists.
+Ordinary message/prompt/tool actions retain their instructions and arguments. Printed details stay
+fenced as untrusted data, including in `events` tool results, and are never interpolated into tool
+arguments. Bound tasks can use `events(action="context")`. Existing tools can address idle owned
+agents, but Events do not automatically wait for busy agents or silently resume stopped/paused ones.
+Use the default `completion_mode="wait"` for one-shot tasks so delegated work finishes before retirement.
+
+The task context contains `task_id`, `reason`, and bounded `events` evidence. Ownership,
+authorization, trigger bookkeeping and causation stay in the host; they are not read back
+from the task's data. The same true/false/unknown condition rules apply during evaluation
+and immediately before dispatch.
+
+Failures remain in history, with grouped error/recovery notices by default (`on_error: {notify: true}`).
+No automatic retries or repair proposals. Agree who retires finished monitors and verify Event/task history.
+Disable an Event to pause it. Deletion retires its ID within its owner/workspace; scoped history
+remains subject to normal retention, and that scope cannot reuse the ID for a different definition.
+
+V1 operations: `list`, `get`, `history`, `create`, `update`, `enable`, `disable`, `delete`,
+`validate`, `authorize`, `revoke`, `run`, `test`, `context`. Manage through conversational tools:
+no Event HTTP API, webhook, YAML import endpoint, or Events WebUI. The existing Schedule HTTP API
+does not expose or manage Event-bound tasks.
+Removing an Event-bound task requires its Event runtime so the protected binding is removed
+with the job. Use the conversational `cron` tool; standalone `wp cron remove` refuses these jobs.

{workpilot-0.35.2 → workpilot-0.36.1}/docs/automation/scheduling.md

@@ -84,10 +84,35 @@ scheduler for its lifetime.
 | `"30 17 * * 5"` | 5:30 PM every Friday |
 | `"0 0 1 * *"` | Midnight on the first of every month |
 
-Event triggers listen for typed events on WorkPilot's internal message bus and fire the job each time a matching event occurs.
+Event triggers listen for typed events on WorkPilot's internal message bus. Ordinary event jobs
+fire when the named event occurs. Tasks with [Event conditions](events.md#combine-time-and-conditions)
+also require their configured boolean conditions to match.
 
 :::
 
+## Fixed checks and Event conditions
+
+Use [Events](events.md) when a task should depend on a fixed-code condition instead of asking an
+agent to evaluate the source on every poll. The Event checker and the task action are separate:
+
+- An Event's time pre-trigger checks independently of a task.
+- A 9:00 task with `event_conditions` performs **new checks at 9:00**; cached results cannot
+  replace those checks.
+- An Event-only task uses `event.checked` and evaluates committed observations of its Events.
+  `event_policy` controls repeated matches, entry transitions, and cooldown.
+
+Both expected true and expected false are supported. Missing, expired, blocked, or failed checks
+are unknown, never false. A nonmatching time tick is skipped without counting as a task failure.
+Jobs without Event conditions retain their existing schedule and action behavior.
+
+Events need separate capability setup and scoped authorization; saving a draft or granting an
+ordinary cron tool call does not enable an Event. See the [Event workflow](events.md#from-a-request-to-an-enabled-check)
+and [authorization](events.md#authorization).
+
+Manage Event-bound tasks through the conversational `cron` tool, not the Schedule HTTP API,
+which does not expose or manage them in V1. Existing cron owns action execution, overlap,
+capacity, and history; there is no separate Event task queue or replay mechanism.
+
 ## Creating jobs
 
 Jobs are managed dynamically via the `cron` tool (from the agent REPL) or the CLI. There is no
@@ -117,6 +142,11 @@ The wizard prompts for name, schedule, and prompt. CLI-created prompt jobs use t
 | **Message** | Static text delivered as-is, no LLM | Simple reminders, notifications |
 | **Tool** | Direct tool execution, no LLM | Deterministic scripts, backups |
 
+Scheduled prompt and heartbeat guidance favors task-relevant fields and changes,
+while preserving explicitly required detail. Necessary full evidence can go in
+`artifact_directory`. Reportable results distinguish completed outcomes from
+failed, blocked, or unapproved actions; existing delivery and silence rules remain unchanged.
+
 ## Session modes
 
 | Mode | Description |
@@ -131,10 +161,13 @@ Use `persistent` for jobs that need to track state across runs.
 Prompt jobs receive host-assigned `state_directory` and `artifact_directory` paths under
 `~/.workpilot/cron/data/`. Both remain stable for the same job even with isolated run sessions.
 Use `state_directory` for a progress ledger and `artifact_directory` for screenshots, logs,
-and reports. Existing file tools create directories on first write. They are in scope only for
-that job's execution and its participating agents; definitions and other jobs remain outside
-this grant. Denied paths and normal risk checks still apply. An unavailable output directory
-blocks the affected file operation, not tasks that only return text.
+and reports. Before each prompt run, WorkPilot initializes usable assigned directories
+without changing existing state files. Initialization failures, including denied paths,
+filesystem permission errors, and redirected directories, are reported in the task context
+and logs instead of blocking text-only work.
+They are in scope only for that job's execution and its participating agents; definitions
+and other jobs remain outside this grant. Normal file permissions, risk checks, and approvals
+still apply.
 
 Prefer instructions such as "save progress in state_directory" over a hard-coded path.
 Existing custom ledgers are not moved or authorized automatically. Directory scope does not
@@ -172,6 +205,13 @@ workpilot cron history [job-id]     # execution history
 workpilot cron doctor               # read-only report of each job's source of truth
 ```
 
+Run history distinguishes completed executions (`success` / `failed`) from skipped or dropped
+ticks and cancelled executions. A `success` record means the run returned normally, not that
+every requested business outcome was completed; inspect its result for remaining blockers.
+Missed-run confirmation records include `confirmation_outcome`, so a timeout is not mistaken
+for an explicit decision to skip. Run IDs and timestamps for newly recorded missed ticks use
+UTC, matching normal executions. A skipped or dropped tick has no execution session link.
+
 ## Notify channels
 
 Jobs can deliver results to channels automatically. When creating a job via the `cron` tool, specify `notify_channels` (for example `["cloud"]`, or `["*"]` for all active channels).
@@ -192,6 +232,17 @@ state model. See [Heartbeat](heartbeat.md).
 
 ## Security
 
+`security.allowed_paths` applies to cron jobs by default, including `isolated` sessions.
+Session isolation resets conversation context, not the runtime's configured path grants.
+The same grants apply to nested `run_code` calls and Coder tools; Coder ownership checks
+remain separate. A folder grant covers its descendants, while a single-file grant does not
+cover the parent directory or sibling temporary files. `security.denied_paths` still wins.
+
+Job-owned `state_directory` and `artifact_directory` scope is additive: it does not replace
+`security.allowed_paths`. Prefer those paths for new job ledgers and outputs. Configured
+`allowed_paths` grants are global, not permissions limited to one job, and do not bypass
+command, credential, publication, or risk-score checks.
+
 Ordinary user-created cron, interval, and event jobs receive a +1 risk-score adjustment
 (capped at 10), and cannot use the configuration-management tool. The built-in heartbeat is
 tagged separately and is exempt from both cron-specific rules; see [Heartbeat](heartbeat.md).
@@ -204,6 +255,7 @@ deny therefore also blocks an already-persisted job.
 ## See also
 
 - [Heartbeat](heartbeat.md) — periodic natural-language maintenance
+- [Events](events.md) — fixed checkers, fresh-at-time conditions, and trusted task handoff
 - [Sub-agents](../agents/subagents.md) — scoped delegated work
 - [Approvals](../security/approvals.md#ordinary-scheduled-job-risk-elevation) — ordinary cron
   risk elevation and the heartbeat exception

{workpilot-0.35.2 → workpilot-0.36.1}/docs/channels/web.md

@@ -110,6 +110,29 @@ control remains a temporary override. Workspace paths refer to the machine runni
 WorkPilot; saving a workspace leaves running work in its current directory and does not
 restart the app.
 
+Use the **Edit configuration** panel in **Settings → Configuration**, or the corresponding
+editor in **Status**, **Security**, **Tools**, **Models**, **Agents**, **Skills**, **Store**,
+**System Prompt**, **Knowledge**, and **Scheduled Jobs**, to change that area's settings
+without leaving the page. **Fields** provides typed controls and schema descriptions;
+**JSON** supports lists, maps, and advanced edits. Runtime status, assembled prompts, audit
+records, history, and usage remain observational data.
+
+Select **Save for next start** to save only the changed fields to the runtime's
+`workpilot.local.yaml`. Advanced edits do not restart WorkPilot or change running work.
+The current security profile may require confirmation or block a change. Concurrent
+configuration changes are rejected without discarding your draft; use **Reload saved** to
+explicitly load the latest values.
+
+**Settings → User Settings → Edit local overrides** edits the saved overrides as JSON.
+Removing a key removes that local override, leaving inherited configuration intact.
+The resulting startup configuration is validated before saving.
+The configuration snapshot follows the loader's precedence, including the selected profile;
+the local overrides editor shows the saved local layer separately.
+**Settings → Raw JSON → Edit raw JSON** edits the configuration snapshot. Unchanged
+credential masks and environment/Secret Store references are preserved. Protected credential
+fields use the Secret Store or the dedicated MCP connection editor rather than the general
+configuration editor.
+
 **Tools → MCP connections** lists configured servers, including disabled ones. Add or edit
 a command/HTTP connection, supply write-only credentials, and connect, enable, disable, or
 remove its local override. Saving connection settings disconnects an existing connection;
@@ -137,19 +160,20 @@ Leaving Chat clears the page-specific request banner and return target; it does
 your conversation draft.
 
 These controls share the browser/Desktop UI and existing Cloud relay. Provider first-use
-setup, advanced security/channel configuration, and automatic runtime restart remain
-separate workflows.
+credential setup and automatic runtime restart remain separate workflows. Existing model
+and MCP connection controls retain their own apply/connect behavior; the general configuration
+editor always saves for the next start.
 
 | Area | What you can do |
 |---|---|
 | **Chat** | Run conversations, review tool progress, approvals, and attachments |
-| **Scheduled** | Create, inspect, enable, disable, run, and review scheduled jobs |
-| **Tools / Skills / Models** | Manage MCP connections, browse full skills and installations, and edit model settings |
-| **Prompts / Knowledge** | Review prompt sections, `MEMORY.md`, and searchable knowledge |
-| **Store** | Discover and manage MCP servers and skills |
-| **Security / Status** | Review credentials, E-stop, security state, channels, and health |
+| **Scheduled** | Manage jobs and edit scheduler/event configuration; non-dynamic jobs remain read-only |
+| **Tools / Skills / Models / Agents** | Manage connections and agents, browse skills, and edit the corresponding defaults and configuration |
+| **Prompts / Knowledge** | Review assembled prompts and knowledge; edit prompt sources and memory/context settings |
+| **Store** | Discover and manage MCP servers, skills, and plugins; edit marketplace/plugin configuration |
+| **Security / Status** | Review E-stop and live state alongside editable security, channel, and runtime configuration |
 | **Sessions / Usage** | Browse conversation history and inspect token/cost usage |
-| **Settings** | Edit basic model/workspace settings and inspect masked advanced configuration |
+| **Settings** | Edit basic settings, advanced configuration, local overrides, and JSON while keeping credentials masked |
 
 Press `Ctrl+K` (`Cmd+K` on macOS) to open the command palette.
 `Ctrl+Shift+D` switches the theme.

{workpilot-0.35.2 → workpilot-0.36.1}/docs/cli/browser.md

@@ -115,15 +115,16 @@ profile.
 
 | Mode | Effective behavior |
 |---|---|
-| `auto` | `workpilot` under `open` or `standard`; `ephemeral` under `controlled` or `restricted` |
+| `auto` | `workpilot` under `open`, `auto`, or `standard`; `ephemeral` under `controlled` or `restricted` |
 | `ephemeral` | Fresh browser context; no persistent profile directory for that run |
 | `workpilot` | Dedicated WorkPilot-managed persistent profile |
 | `system` | The user's real OS browser data; high risk and unavailable under `controlled` or `restricted` |
 
 An explicit `persistent_profile` path overrides `profile_mode` for the agent browser tool.
 Pointing it at a known real browser profile receives the same protections as `system` mode:
-the first launch is risk score 8 under `open`/`standard`, and configured or runtime use is
-rejected under `controlled`/`restricted`.
+the first launch is risk score 8 under `open`/`auto`/`standard`, and configured or runtime use is
+rejected under `controlled`/`restricted`. The Auto security profile always requires human
+approval for that system-profile launch; it is distinct from the browser's `profile_mode: auto`.
 
 Firefox has no automatically selected `system` profile because its profile layout can contain
 multiple profiles. A deliberately selected Firefox profile requires an explicit persistent

workpilot-0.36.1/docs/cli/hooks.md

@@ -0,0 +1,130 @@
+# workpilot hooks
+
+::: warning Experimental new feature
+Hook interfaces, schema, and behavior may change incompatibly without notice. Do not depend on
+stable compatibility.
+:::
+
+<!-- BEGIN GENERATED CLI HELP: workpilot hooks -->
+
+```text
+Usage: workpilot hooks [OPTIONS] COMMAND [ARGS]...
+
+  Review native command hooks
+
+Options:
+  --help  Show this message and exit.
+
+Commands:
+  validate  Validate exactly one version-1 hook envelope without writing trust state.
+  list      List effective discovered command hooks and isolated diagnostics.
+  review    Review pending handler content and record enable/disable choices.
+  enable    Enable one currently reviewed handler.
+  disable   Disable one handler and record its current digest as reviewed.
+
+  EXPERIMENTAL — Experimental: hook interfaces, schema, and behavior may change incompatibly without
+  notice.
+```
+
+<!-- END GENERATED CLI HELP: workpilot hooks -->
+> [中文版](../zh-cn/cli/hooks.md)
+`workpilot hooks` manages reviewed native command hooks; validate, review, then enable trusted local integrations (`wp` is an alias).
+## Schema, ordering, and trust
+UTF-8 files use `{ "$schema": string?, "version": 1, "hooks": object }`, the five lifecycle events, and handlers with `executable`, optional `args`, and relative `scriptFiles`. Sorted user, `.agents`, project, then plugin declarations append; invalid files are isolated. Review state stores the handler/scripts SHA-256 digest. Hooks run without a shell for at most 10 seconds; failed `PreToolUse` blocks the tool and other failures are logged.
+
+An explicit `executable` file path is also fingerprinted and rechecked before launch; relative
+paths use the hook document's directory. Changing its content or symlink target requires review
+again, including renewal of reviews saved before executable fingerprinting. Bare names such as
+`python` use the host's trusted PATH instead.
+
+Interactive startup and `hooks review` show each pending handler's full executable, arguments, and
+declared script paths before selection. Inspect the referenced scripts before enabling them. Enter
+saves selected handlers as enabled and unselected handlers as disabled; Esc leaves them pending.
+Without a TTY, pending handlers remain inactive.
+
+Hook definitions stay bound to the startup catalog. Plugin reload reports a restart requirement
+for catalog additions, edits, or removals rather than hot-swapping handlers. Existing handlers keep
+their per-launch content checks until restart; restart to apply changes and review new content.
+
+## workpilot hooks validate
+<!-- BEGIN GENERATED CLI HELP: workpilot hooks validate -->
+
+```text
+Usage: workpilot hooks validate [OPTIONS] {PATH}
+
+  Validate exactly one version-1 hook envelope without writing trust state.
+
+Arguments:
+  PATH  [required]
+
+Options:
+  --help  Show this message and exit.
+```
+
+<!-- END GENERATED CLI HELP: workpilot hooks validate -->
+## workpilot hooks list
+<!-- BEGIN GENERATED CLI HELP: workpilot hooks list -->
+
+```text
+Usage: workpilot hooks list [OPTIONS]
+
+  List effective discovered command hooks and isolated diagnostics.
+
+Options:
+  -c, --config <str>   Config file or directory  [default: .]
+  -p, --profile <str>  Config profile
+  --help               Show this message and exit.
+```
+
+<!-- END GENERATED CLI HELP: workpilot hooks list -->
+## workpilot hooks review
+<!-- BEGIN GENERATED CLI HELP: workpilot hooks review -->
+
+```text
+Usage: workpilot hooks review [OPTIONS]
+
+  Review pending handler content and record enable/disable choices.
+
+Options:
+  -c, --config <str>   Config file or directory  [default: .]
+  -p, --profile <str>  Config profile
+  --help               Show this message and exit.
+```
+
+<!-- END GENERATED CLI HELP: workpilot hooks review -->
+## workpilot hooks enable
+<!-- BEGIN GENERATED CLI HELP: workpilot hooks enable -->
+
+```text
+Usage: workpilot hooks enable [OPTIONS] {HANDLER_ID}
+
+  Enable one currently reviewed handler.
+
+Arguments:
+  HANDLER_ID  [required]
+
+Options:
+  -c, --config <str>   Config file or directory  [default: .]
+  -p, --profile <str>  Config profile
+  --help               Show this message and exit.
+```
+
+<!-- END GENERATED CLI HELP: workpilot hooks enable -->
+## workpilot hooks disable
+<!-- BEGIN GENERATED CLI HELP: workpilot hooks disable -->
+
+```text
+Usage: workpilot hooks disable [OPTIONS] {HANDLER_ID}
+
+  Disable one handler and record its current digest as reviewed.
+
+Arguments:
+  HANDLER_ID  [required]
+
+Options:
+  -c, --config <str>   Config file or directory  [default: .]
+  -p, --profile <str>  Config profile
+  --help               Show this message and exit.
+```
+
+<!-- END GENERATED CLI HELP: workpilot hooks disable -->

{workpilot-0.35.2 → workpilot-0.36.1}/docs/cli/init.md

@@ -86,7 +86,8 @@ The normal wizard detects common local tools, then covers six areas:
 
 1. **GitHub Copilot provider** — keep an existing credential, sign in, or defer. New credentials
    are stored through the Secret Store when available.
-2. **Security profile** — choose `open`, `standard`, `controlled`, or `restricted`.
+2. **Security profile** — choose `open`, `auto`, `standard`, `controlled`, or `restricted`.
+   Auto reviews task authorization within Standard's access boundaries; Standard remains the default.
 3. **Web UI** — enable or disable the local browser experience.
 4. **Cloud connection** — choose hosted WorkPilot Cloud, a self-hosted gateway, or local-only
    operation. First-time cloud choices are verified when possible.

{workpilot-0.35.2 → workpilot-0.36.1}/docs/cli/msgraph.md

@@ -108,7 +108,7 @@ incremental delegated permission. The browser profile can reuse an existing Micr
 but password, MFA, account choice, and consent remain manual when prompted.
 
 In non-interactive agent contexts, the Graph tool does not silently open a browser. A cold
-interactive sign-in is separately risk-gated under `open`/`standard`, while
+interactive sign-in is separately risk-gated under `open`/`auto`/`standard`, while
 `controlled`/`restricted` agent execution remains cache/broker-only. The direct
 `workpilot msgraph add-scope` CLI command is an explicit operator action and attempts the
 visible browser flow regardless of the agent runtime profile.