@pellux/goodvibes-agent 1.2.0 → 1.4.1

package/docs/README.md

@@ -33,11 +33,11 @@ Agent-owned model tools expose Agent-controlled product surfaces plus operator/a
 - `setup` for the first-run path: status, item lookup, checkpoint inspect/save/clear, connected-host token repair, setup smoke, finish onboarding, and GoodVibes settings import through existing setup gates.
 - `models` for direct provider/model route readiness, exact route/provider inspection, provider and subscription posture, local model cookbook guidance, and confirmed local server smoke checks while lower-level provider/model harness modes remain compatibility/detail routes.
 - `settings` for first-class Agent settings list/get/set/reset and GoodVibes settings import preview/apply through existing redacted confirmation gates.
-- `agent_harness` for the same assistant-first cockpit shown in TUI Home, searchable mode discovery, workspace actions, GoodVibes settings import workspace parity, detailed setup posture, ordered channel setup guide, channel triage, redacted channel delivery receipts, slash commands, settings compatibility modes, panels, UI surfaces including the confirmed connected browser cockpit/PWA route with category coverage, mobile/PWA controls, and receipt-gap reporting, keybindings, tool schemas, model detail compatibility routes, local-vs-delegated execution posture, process monitor/live tail/tool inspector supervision routes, file edit recovery, ongoing-work intake, visible autonomy queue with live research run, connected-host task, approval, automation run, and schedule records/log tails, service/daemon posture, connected-host capability/status, posture catalogs, and operator/audit release artifact inspection.
-- `computer` for direct browser/PWA, browser/screenshot/desktop-control route planning, setup, MCP, and confirmed visible browser cockpit handoffs; `device` remains the companion/mobile/voice/TTS/provider route while lower-level pairing/media/UI harness modes remain compatibility/detail routes.
+- `agent_harness` for the same assistant-first cockpit shown in TUI Home, searchable mode discovery, workspace actions, GoodVibes settings import workspace parity, detailed setup posture, ordered channel setup guide, channel triage, redacted channel delivery receipts, slash commands, settings compatibility modes, panels, UI surfaces including the confirmed connected browser cockpit/PWA route with certified category coverage, mobile/PWA controls, and first-run receipt evidence, keybindings, tool schemas, model detail compatibility routes, local-vs-delegated execution posture, process monitor/live tail/tool inspector supervision routes, file edit recovery, ongoing-work intake, visible autonomy queue with live research run, connected-host task, approval, automation run, and schedule records/log tails, service/daemon posture, connected-host capability/status, posture catalogs, and operator/audit release artifact inspection.
+- `computer` for direct browser/PWA readiness, certified browser-native category routes and first-run receipts when the SDK/daemon publishes them, browser/screenshot/desktop-control route planning, setup, MCP, and confirmed visible browser cockpit handoffs; `device` remains the companion/mobile/voice/TTS/provider route while lower-level pairing/media/UI harness modes remain compatibility/detail routes.
 - `agent_knowledge` and `agent_knowledge_ingest` for isolated Agent Knowledge.
 - `vibe` for direct VIBE.md personality status/show, confirmed project or global VIBE.md initialization, and confirmed VIBE.md-to-persona import.
-- `personal_ops` for direct daily briefing, readiness status, request intake, lane inspection, and one confirmed read-only inbox/calendar connector operation with structured next routes while lower-level harness modes remain available for detailed inspection.
+- `personal_ops` for direct daily briefing, readiness status, queue review, daemon/SDK inbox/calendar read-model records, request intake, lane inspection, and one confirmed read-only inbox/calendar connector operation with structured next routes while lower-level harness modes remain available for detailed inspection.
 - `agent_local_registry` and `agent_learning_consolidation` for Agent-local memory, notes, personas, skills, bundles, routines, confirmed duplicate-consolidation phases with receipts, and `agent_harness` learning-curator modes for ranked review/setup/stale, duplicate-consolidation, reviewed-note, completed-work, completed-research, and saved-session memory/behavior proposals.
 - `agent_work_plan` for visible local work-plan state and confirmed dispatch of approved plan items to visible agents, with linked receipts surfaced in orchestration closeout.
 - `agent_operator_briefing` and `agent_operator_action` for public connected operator state and exact confirmed actions.

package/docs/connected-host.md

@@ -73,13 +73,13 @@ The model can inspect this boundary with `host action:"capabilities"`. By defaul
 
 The model can inspect the public operator method catalog with `host action:"methods"`. That report is generated from the GoodVibes SDK contract, not a stale hand-maintained shortlist. To inspect one method without parsing the full report, use `host action:"method"` with `methodId`, `target`, or `query`. Execute exact daemon methods with `agent_operator_method`: read-only routes can run directly; write/admin routes require `confirm:true` and `explicitUserRequest`. Lower-level `operator_methods` and `operator_method` remain compatibility routes.
 
-The model can inspect service posture with `host action:"services"`. That report exposes endpoint binding, network-facing posture, issues, and redacted-log diagnostics used by status, doctor, and support bundles. Use `includeParameters:true` when reachability probes and redacted log tail are needed. To inspect one endpoint, use `host action:"service"` with `endpointId`, `target`, or `query`; valid endpoint ids are `controlPlane`, `httpListener`, and `web`. The connected browser cockpit/PWA is the visible UI surface `connected-browser-cockpit`; `computer action:"browser"` inspects readiness and `computer action:"open_browser" confirm:true explicitUserRequest:"..."` opens the configured URL through the existing confirmed surface route. `ui_surface surfaceId:"connected-browser-cockpit"` remains available for detailed compatibility inspection and reports Agent workspace category coverage, mobile/PWA control routes, the Agent onboarding marker, and the unpublished browser/PWA first-run receipt contract. Service lifecycle and listener changes must use setup or confirmed daemon operator methods.
+The model can inspect service posture with `host action:"services"`. That report exposes endpoint binding, network-facing posture, issues, and redacted-log diagnostics used by status, doctor, and support bundles. Use `includeParameters:true` when reachability probes and redacted log tail are needed. To inspect one endpoint, use `host action:"service"` with `endpointId`, `target`, or `query`; valid endpoint ids are `controlPlane`, `httpListener`, and `web`. The connected browser cockpit/PWA is the visible UI surface `connected-browser-cockpit`; `computer action:"browser"` inspects readiness and `computer action:"open_browser" confirm:true explicitUserRequest:"..."` opens the configured URL through the existing confirmed surface route. `ui_surface surfaceId:"connected-browser-cockpit"` remains available for detailed compatibility inspection and reports Agent workspace category coverage, mobile/PWA control routes, the Agent onboarding marker, and browser/PWA first-run evidence. Certified SDK/daemon browser/PWA category-route records can make the cockpit `browser-native-ready` only when every Agent workspace category has schema/version/publication/publisher/provenance/freshness-cursor/receipt metadata, exact inspect/open routes, and mobile/touch evidence. Certified browser/PWA first-run records add manifest, service-worker, install, and offline evidence with redacted URLs and summaries. Start/setup readiness can also satisfy the setup checklist from saved durable artifacts or live SDK/daemon setup read models when the connected host publishes them, and reports the gap when no receipt exists. Service lifecycle and listener changes must use setup or confirmed daemon operator methods.
 
 For setup or host repair asks, start with `setup action:"repair"`. It is read-only and chooses the next safe route for the current setup blocker or a named target: connected-host status, a `services.status` receipt, confirmed token repair, user-run bootstrap commands, or no lifecycle action when the host is already reachable. It does not start, install, restart, write tokens, import settings, or open UI by itself.
 
 The model can inspect live connected-host readiness with `host action:"status"`. That report uses the same status probe as the CLI: it checks the connected-host status route, verifies host compatibility, checks isolated Agent Knowledge when token and compatibility posture allow it, reports endpoint bindings and token posture without printing token values, returns actionable findings, and includes a compact `modelRoute` for follow-up diagnostics. `includeParameters:true` adds route family and capability detail. Lower-level `connected_host_status` and `daemon_status` remain compatibility routes.
 
-The model can inspect companion pairing posture through `device action:"status"` and inspect one pairing/mobile route with `device action:"capability" capabilityId:"..."`. Lower-level `agent_harness` modes `pairing_posture` and `pairing_route` remain available for detailed compatibility. Those routes report the control-plane endpoint binding, pairing surface id, token presence/fingerprint, route catalog, and a companion device capability map for pairing, mobile command routing, browser/PWA, voice/TTS, notifications, browser/desktop control, and unpublished camera/location posture without returning raw tokens or QR payloads. Pairing display, manual token display, companion connection, channel delivery, task, approval, provider/model, and attachment actions remain visible user flows.
+The model can inspect companion pairing posture through `device action:"status"` and inspect one pairing/mobile route with `device action:"capability" capabilityId:"..."`. Lower-level `agent_harness` modes `pairing_posture` and `pairing_route` remain available for detailed compatibility. Those routes report the control-plane endpoint binding, pairing surface id, token presence/fingerprint, route catalog, and a companion device capability map for pairing, mobile command routing, browser/PWA, voice/TTS, notifications, browser/desktop control, and camera/screen/location posture without returning raw tokens or QR payloads. Camera, screen, location, local device command, and wake-word capabilities count as ready only when certified SDK/daemon records publish permission scope, schema/version/publication/publisher/provenance/freshness-cursor/receipt evidence, and exact inspect/control routes. Pairing display, manual token display, companion connection, channel delivery, task, approval, provider/model, attachment, capture, permission repair, and device command actions remain visible user flows.
 
 Agent Knowledge is its own product segment. Agent uses `/api/goodvibes-agent/knowledge/*` only and must not fall back to default knowledge or other product-specific knowledge routes. Agent normalizes public Agent-route scope aliases and rejects successful-looking responses that carry known non-Agent payload markers.
 

package/docs/getting-started.md

@@ -40,15 +40,15 @@ Use the interactive workspace first. CLI subcommands are secondary support paths
 
 Primary first-run areas:
 
-- Setup: guided first-run wizard with progress, current-step route hints, saved setup checkpoints, checkpoint auto-advance evidence when a saved step is already ready, backtracking routes, setup-smoke rerun/save routes, repeated-blocker focus from saved smoke history, and closeout state from critical blocker, saved smoke, and user completion-marker evidence; visible checklist for runtime, connected-host auth, provider/model, install smoke, and follow-on capabilities; prioritized first-run plan; primary handoffs from every actionable setup row to the safest visible form, diagnostic, or confirmed route; GoodVibes settings import preview/apply; read-only setup repair decisions; token-safe install smoke checks; confirmed setup smoke execution with saved redacted evidence artifacts and Home/setup latest-result plus history/trend surfacing; confirmed onboarding finish marker write; model readiness scores; Model Routing readiness and benchmark-evidence actions; hardware-scored local model cookbook with setup/download guidance; confirmed benchmark action/history; connected-host compatibility; live service probe evidence; token-safe connected-host auth posture with exact pairing route ids; confirmed local token create/repair; offline GoodVibes host bootstrap commands; diagnostic/status repair recommendations; inspect-first confirmed service install/start/restart routes with success criteria and certified service receipt outcomes; Agent Knowledge readiness; profiles; support bundles; subscriptions; and auth review.
+- Setup: guided first-run wizard with progress, current-step route hints, saved setup checkpoints, checkpoint auto-advance evidence when a saved step is already ready, backtracking routes, setup-smoke rerun/save routes, repeated-blocker focus from saved smoke history, and closeout state from critical blocker, saved smoke, durable setup receipt, and user completion-marker evidence; visible checklist for runtime, connected-host auth, provider/model, install smoke, and follow-on capabilities; prioritized first-run plan; primary handoffs from every actionable setup row to the safest visible form, diagnostic, or confirmed route; GoodVibes settings import preview/apply; read-only setup repair decisions; token-safe install smoke checks; confirmed setup smoke execution with saved redacted evidence artifacts and Home/setup latest-result plus history/trend surfacing; setup readiness that can auto-advance connected-host service/auth/install-smoke/browser-PWA rows from saved durable artifacts, live SDK/daemon setup receipt read models, or ordered setup receipt event streams with secret-looking receipt text redacted and schema/version/provenance/publication/cursor evidence surfaced for certified receipts; confirmed onboarding finish marker write; route-level provider-health-backed model readiness scores; Model Routing readiness and benchmark-evidence actions; hardware-scored local model cookbook with setup/download guidance; certified local serving diagnostics with host-published start/repair route evidence; confirmed benchmark action/history; connected-host compatibility; live service probe evidence; token-safe connected-host auth posture with exact pairing route ids; confirmed local token create/repair; offline GoodVibes host bootstrap commands; diagnostic/status repair recommendations; inspect-first confirmed service install/start/restart routes with success criteria and certified service receipt outcomes; Agent Knowledge readiness; profiles; support bundles; subscriptions; and auth review.
 - Home: assistant cockpit lanes for setup, chat/model choice, browser cockpit/PWA handoff, project work, Personal Ops, research/docs, background supervision, and safety/recovery, plus briefing, model refresh, health, doctor, and compatibility actions.
 - Knowledge: isolated Agent Knowledge status, ask/search, inspection, and confirmed ingest.
-- Research: read-only web research and URL inspection, a visible Research briefing next-action queue, workflow planning with bounded public source-candidate search, browser-runner and visual-report readiness, project-local visible research runs with log tails, browser-backed runner readiness/fallback posture, source queue, credibility review, reviewed-source bundles, plus confirmed sourced report artifacts with source maps, citation coverage checks, repair hints, and optional visual report packets.
+- Research: read-only web research and URL inspection, a visible Research briefing next-action queue, workflow planning with bounded public source-candidate search, certified live SDK/daemon browser-runner and visual-report render evidence when published, project-local visible research runs with log tails, browser-backed runner readiness/fallback posture, source queue, credibility review, reviewed-source bundles, plus confirmed sourced report artifacts with source maps, citation coverage checks, repair hints, and optional visual report packets.
 - Documents & Compare: versioned markdown document drafts, review comments, AI suggestion review, draft browse/show/create/revise/review/suggest/accept/reject/artifact-attach/artifact-insert/export with reviewer-ready comment and suggestion summaries, chronological review packet timeline across document/comment/suggestion/compare/judgment/route-decision/packet-preset/handoff/archive events with stale preset attention, a read-only review packet wizard with progress/current-step routes/backtracking/final archive review/refreshed-preset lineage/share handoff, visible reviewer-readiness preflight before export/archive/apply, inline readiness badges at document export, reviewer handoff/archive, and route-apply forms, packet defaults that prefill the next export/handoff/archive/apply/leave-unchanged/save-preset/share ids from the latest review packet while falling back to saved preset metadata only when live evidence is missing, uploads, exports, source checks, generated media artifacts, saved artifact browse/show/export/package/archive, reviewed artifact-to-Knowledge promotion, saved packet preset save/list/show/refresh routes with missing/superseded id freshness checks and confirmed refresh into a new preset artifact, confirmed reviewer packet share through `agent_review_packet_share` with channel target preview and no ZIP-byte transcript output, saved text artifact reuse in blind comparison, and confirmed blind model comparison with delayed reveal, durable JSON comparison artifacts, saved review boards, side-by-side reviewer views, split-pane reviewer handoff diffs with section jumps plus recent-handoff defaults and visible recent choices, saved judgment artifacts, confirmed apply and leave-unchanged route-decision receipts, task/document/benchmark-filtered preference analytics/synthesis, markdown report export, reviewer handoff artifacts, one-click reviewer handoff ZIP archives with matching route-decision receipt evidence, and confirmed winner route updates.
-- Personal Ops: a read-only daily briefing plan across inbox, agenda, tasks, reminders, routines, delivery, notes, and the autonomy queue; a read-only review queue for saved inbox thread/calendar event items, refreshable provider-read routes, and follow-up boundaries; inbox/calendar connector readiness; request intake that turns "triage my inbox", "brief my calendar", task, reminder, note, routine, and delivery asks into the safest lane/route/fields/confirmation boundary, email/calendar-capable MCP setup routes, expanded connector tool classification for read-only versus write-like inbox/calendar actions, schema-derived operation records with required fields, sample inputs, schema routes, confirmation flags, and fresh-read routes, inbox triage/draft and calendar agenda/conflict workflow cards with inspect routes, ordered execution plans for connector reads/local drafting/confirmed effects, confirmed read-only MCP execution for selected inbox/calendar reads with bounded redacted output, normalized review cards, optional saved redacted review-card artifacts, structured next-route packets for refresh/lane/queue/artifact/local-draft/confirmed-effect boundaries, and saved review artifacts resurfaced as redacted inbox thread/calendar event queue records with artifact inspect routes, freshness status, confirmed refresh routes when a matching read connector is ready, local draft/reminder follow-up routes, and confirmed provider-effect boundaries, plus live records for Agent-owned notes, routines, schedule receipts, delivery channels, and redacted delivery receipts.
+- Personal Ops: a read-only daily briefing plan across inbox, agenda, tasks, reminders, routines, delivery, notes, and the autonomy queue; a read-only review queue for saved inbox thread/calendar event items, refreshable provider-read routes, daemon/SDK provider read-model records, and follow-up boundaries; inbox/calendar connector readiness; request intake that turns "triage my inbox", "brief my calendar", task, reminder, note, routine, and delivery asks into the safest lane/route/fields/confirmation boundary, email/calendar-capable MCP setup routes, expanded connector tool classification for read-only versus write-like inbox/calendar actions, schema-derived operation records with required fields, sample inputs, schema routes, confirmation flags, and fresh-read routes, inbox triage/draft and calendar agenda/conflict workflow cards with inspect routes, ordered execution plans for connector reads/local drafting/confirmed effects, confirmed read-only MCP execution for selected inbox/calendar reads with bounded redacted output, normalized review cards, optional saved redacted review-card artifacts, structured next-route packets for refresh/lane/queue/artifact/local-draft/confirmed-effect boundaries, saved review artifacts resurfaced as redacted inbox thread/calendar event queue records, certified provider-effect receipts for inbox/calendar/task/reminder outcomes, and fresh daemon/SDK-published inbox/calendar/task/reminder queue records with durable ids, labels, redacted snippets/notes, agenda windows, conflict signals, due times, cadence, delivery targets, freshness status, source paths, schema/version/publication/publisher/provenance/receipt evidence, read-only inspect routes, local draft/reminder follow-up routes, and confirmed provider-effect boundaries only when matching routes are published, plus live records for Agent-owned notes, routines, schedule receipts, delivery channels, and redacted delivery receipts.
 - Memory & Skills: VIBE.md personality, project context files, local memory, notes, personas, skills, routines, learned behavior capture, prompt injection limited to safe VIBE.md, safe project context, and reviewed/confident setup-ready behavior, visible Local Context and Personas workspace health counts for VIBE.md/project context files, setup/curator visibility for blocked or truncated VIBE.md files, model-visible context inspection for blocked or truncated project context files, a Prompt context action that shows the currently applied prompt order, recent durable receipt ids, selected/suppressed context records, and approximate token budget, a Prompt plan action that explains prompt-active records, suppressed review/setup work, proposal queues, consolidation queues, and scored review routes before context expands, and a learning curator for review/setup/stale/duplicate-consolidation/reviewed-note/completed-work/completed-research/saved-session memory and behavior candidates, including guided duplicate-consolidation phase helpers with receipts.
 - Channels: companion pairing, an ordered channel setup guide, channel readiness, channel triage, notification targets, allowlist/status review, redacted confirmed-send receipts, and confirmed sends.
-- Voice & Media: TTS setup, image input, confirmed generated media, voice workflow posture, device capability readiness, and browser/PWA readiness.
+- Voice & Media: TTS setup, image input, confirmed generated media, voice workflow posture, certified companion device capability readiness when the SDK/daemon publishes permission-scoped records, and browser/PWA readiness with certified category-route and first-run receipt evidence when the connected host publishes it.
 - Work & Automation: work-plan tracking, approvals, schedules, reminders, and explicit operator actions.
 - Operator Runtime: daemon status, method discovery, confirmed write/admin routes, visible autonomous agents, and cancellation/status follow-up.
 
@@ -69,20 +69,20 @@ Common model routes:
 
 | Need | Tool Or Mode |
 | --- | --- |
-| Choose the best route for a user task | `route action:"plan" query:"..."`; host diagnostics route through `host action:"status"`; settings route through `settings action:"list"`; model provider/local-cookbook/smoke/route-fit requests route through `models action:"provider|local|smoke|route"`; Personal Ops briefing/queue/fresh-read/connector requests route through `personal_ops action:"briefing|queue|intake|lane"`; reminders/schedules route through `schedule action:"list"`; local background commands route through `execution action:"processes"`; interactive PTY/stdin/sudo questions route through `execution action:"process_capabilities"`; external memory-provider/backend/sync requests route through `memory action:"provider"` or the provider checklist, which now shows provider-specific next routes and missing receipt fields before provider effects; browser-backed research runner requests route through `research action:"runner"`; visual research report rendering routes through `research action:"plan"` plus report artifacts; voice workflow and TTS-provider requests route through `device action:"voice|provider"`; browser cockpit/PWA requests route through `computer action:"browser"` before confirmed open handoff; channel setup/triage/delivery-receipt/send requests route through `channels action:"setup|triage|deliveries|channel"`; permission posture/finding/blocked-action questions route through `security action:"status|finding|explain"`; support-bundle requests route through `support action:"status|bundle"`; saved-session/bookmark/continuity requests route through `sessions action:"list|get"`; release readiness/evidence requests route through `audit action:"readiness|evidence|item|artifact"`; file undo/redo routes through `execution action:"recovery"`; media generation routes through provider readiness plus `agent_media_generate`; screenshot/browser/desktop-control tasks route through `computer action:"plan"`; lower-level `agent_harness mode:"route_decision"` remains available for compatibility/detail |
+| Choose the best route for a user task | `route action:"plan" query:"..."`; host diagnostics route through `host action:"status"`; settings route through `settings action:"list"`; model provider/local-cookbook/smoke/route-fit requests route through `models action:"provider|local|smoke|route"`; Personal Ops briefing/queue/fresh-read/connector requests route through `personal_ops action:"briefing|queue|intake|lane"`; reminders/schedules route through `schedule action:"list"`; local background commands route through `execution action:"processes"`; interactive PTY/stdin/sudo questions route through `execution action:"process_capabilities"`, which surfaces certified daemon runtime records when published; external memory-provider/backend/sync requests route through `memory action:"provider"` or the provider checklist, which now shows provider-specific next routes, certified live read-model status when published, certified receipt evidence, and remaining checks before provider effects; browser-backed research runner requests route through `research action:"runner"`; visual research report rendering routes through `research action:"plan"` plus report artifacts; voice workflow and TTS-provider requests route through `device action:"voice|provider"`; browser cockpit/PWA requests route through `computer action:"browser"` before confirmed open handoff; channel setup/triage/delivery-receipt/send requests route through `channels action:"setup|triage|deliveries|channel"`; permission posture/finding/blocked-action questions route through `security action:"status|finding|explain"`; support-bundle requests route through `support action:"status|bundle"`; saved-session/bookmark/continuity requests route through `sessions action:"list|get"`; release readiness/evidence requests route through `audit action:"readiness|evidence|item|artifact"`; file undo/redo routes through `execution action:"recovery"`; media generation routes through provider readiness plus `agent_media_generate`; screenshot/browser/desktop-control tasks route through `computer action:"plan"`; lower-level `agent_harness mode:"route_decision"` remains available for compatibility/detail |
 | Harness mode discovery | `agent_harness mode:"modes"`, `mode:"mode"` |
 | Workspace actions | `workspace action:"status|actions|action|run"`; lower-level workspace harness modes remain available for compatibility/detail |
 | Slash commands | `workspace action:"commands|command|run_command"`; lower-level command harness modes remain available for compatibility/detail |
 | Settings | `settings action:"list|get|set|reset|import"`; lower-level `agent_harness mode:"settings"`, `mode:"get_setting"`, `mode:"set_setting"`, `mode:"reset_setting"` remain available for compatibility/detail |
 | GoodVibes settings import | `settings action:"import"` previews by default; apply with `confirm:true explicitUserRequest:"..."`; `import_goodvibes_settings action:"preview|apply"` remains available |
-| Visible UI and devices | `workspace action:"surfaces|surface|open|panels|panel|open_panel"` for visible navigation; `computer action:"status|plan|control|browser|setup|mcp|open_browser"` for browser/PWA, browser/screenshot/desktop-control planning, and computer-use UX; `device action:"status|capability|voice|provider|open_tts_provider|open_tts_voice"` for device/voice UX |
+| Visible UI and devices | `workspace action:"surfaces|surface|open|panels|panel|open_panel"` for visible navigation; `computer action:"status|plan|control|browser|setup|mcp|open_browser"` for browser/PWA readiness, certified browser-native category routes and first-run receipts, browser/screenshot/desktop-control planning, and computer-use UX; `device action:"status|capability|voice|provider|open_tts_provider|open_tts_voice"` for device/voice UX |
 | Keybindings | `workspace action:"shortcuts|keybindings|keybinding|run_keybinding|set_keybinding|reset_keybinding"` |
 | Tool contracts | `agent_harness mode:"tools"`, `mode:"tool"` |
 | Agent Knowledge | `agent_knowledge`, `agent_knowledge_ingest` |
 | Research runs, sources, and reports | `research action:"briefing|plan|search|runner|runs|run|sources|source|bundle|reports|report_artifact|create_run|start_run|checkpoint|pause|resume|cancel|complete|fail|delete_run|add_source|review_source|reject_source|use_source|delete_source|report"`; lower-level `agent_research_runs`, `agent_research_sources`, `agent_research_report`, and harness research modes remain available for detailed inspection |
 | Personal operations | `personal_ops action:"briefing|status|queue|intake|lane|read"`; lower-level `agent_harness mode:"personal_ops_briefing"`, `mode:"personal_ops_queue"`, `mode:"personal_ops_intake"`, `mode:"personal_ops"`, `mode:"personal_ops_lane"`, and `mode:"run_personal_ops_read"` remain available for detailed inspection |
 | Visible autonomy | `autonomy action:"intake|queue|item|status"`; lower-level `agent_harness mode:"autonomy_intake"`, `mode:"autonomy_queue"`, and `mode:"autonomy_queue_item"` remain available for detailed inspection |
-| Model and local model choice | `models action:"status|route|local|providers|provider|smoke"`; lower-level `agent_harness mode:"model_routing"`, `mode:"model_route"`, `mode:"provider_accounts"`, `mode:"provider_account"`, and `mode:"run_local_model_smoke"` remain available for detailed inspection |
+| Model and local model choice | `models action:"status|route|local|providers|provider|smoke"` for route readiness with route-level provider-health records, local cookbook, certified daemon-published local serving diagnostics, provider posture, and confirmed local smoke checks; lower-level `agent_harness mode:"model_routing"`, `mode:"model_route"`, `mode:"provider_accounts"`, `mode:"provider_account"`, and `mode:"run_local_model_smoke"` remain available for detailed inspection |
 | Local background processes | `execution action:"processes|process"` for inspection, `execution action:"process_capabilities"` for PTY/stdin/sudo posture, `terminal command:"..." background:true` to start, and `process action:"list|poll|log|wait|kill"` for lifecycle controls |
 | Documents, artifacts, compare | `agent_harness mode:"document_ops"`, `mode:"document_ops_lane"`, `agent_documents`, `agent_review_packet_presets`, `agent_review_packet_share`, `agent_artifacts`, `agent_model_compare` |
 | VIBE.md, project context, and local memory/notes/personas/skills/routines | `vibe action:"status|show|init|import_persona"`, `/vibe`, `context action:"status|files|file|prompt|receipts|receipt"`, `memory action:"status|provider|curator|candidate|list|search|get"` for local memory plus external provider next routes/checklists/receipt contracts, `agent_local_registry`, `agent_learning_consolidation`, or confirmed workspace actions |
@@ -154,7 +154,7 @@ Agent commands fail closed if the route is unavailable or a successful-looking r
 
 The Knowledge workspace also exposes route-backed and command-backed workflows for issue review, prompt packet previews, context-selection explain output, consolidation, and reindex. Read-only ask/search/list/get/map/connector/packet/explain paths do not require mutation confirmation. Ingest, review-issue, consolidation, and reindex paths require explicit confirmation.
 
-Use Agent Workspace -> Research for read-only web research, URL inspection, visible checkpointable research run state, a read-only Research briefing queue, bounded public source-candidate search, browser-backed runner readiness, project-local source queue review, reviewed-source bundles, saved report inspection, and confirmed sourced report artifacts. Research requests do not ingest sources. The Research workspace shows browser-runner and visual-report readiness, the direct `research` run/source/report routes, a Research briefing action for `research action:"briefing"`, a Plan workflow action for `research action:"plan"`, a Public source search action for `research action:"search"`, a Browser runner readiness action for `research action:"runner"`, and a Report artifacts action for `research action:"reports"`. Use `research action:"briefing"` first when the model needs one read-only next-action queue across visible runs, source review, saved report artifacts, browser readiness, and exact follow-up routes. Use `research action:"search"` for one bounded public web search that returns capture-ready source candidates plus exact confirmed `add_source` routes; pass `runId` to use an existing visible run's saved question and receive run-specific start/checkpoint follow-up routes. It does not create runs or write source records by itself. Use `research action:"runner"` for the direct browser-backed runner readiness contract and setup/fallback routes. Use `research action:"plan"` when the model needs one ordered route plan for a research request or existing run; it returns visible-run, source-collection, source-review, visual-report-save, and Knowledge-promotion steps plus browser-runner and visual-report packet contracts without performing any of them. Research run records keep the user-facing question, phase, progress, checkpoints, log tails, source ids, next steps, confirmed lifecycle routes, and runner posture that tells the model whether browser-backed research is ready, needs setup review, or should fall back to public web/fetch routes without starting hidden background work. Research run detail and mutation outputs include next-route packets for inspect, briefing, workflow, run-bound search, source queue, checkpoint, report save, artifact inspection, and Knowledge promotion when a report artifact exists. The browser-runner contract names the required visible run controls, source-capture receipts, bounded logs, report handoff, setup routes, and fallback routes before live browser execution is treated as ready. Source queue records keep credibility, score, report-ready source lines, source bundle handoffs, and safe routes; source detail and mutation outputs point to the next review, reject, bundle, report, mark-used, artifact inspection, or optional Knowledge promotion route without performing those effects. Saved report artifacts keep a source map, citation coverage metadata, repair hints, optional strict body-citation enforcement, optional `visualReport:true` packet sections for at-a-glance summary, evidence matrix, findings board, dated source/comparison view, open questions, next actions, and handoff checklist, and next-route packets for report inspection, artifact export/archive, Knowledge promotion, report listing, and visible run completion when `runId` is supplied. Use `research action:"report_artifact" artifactId:"..."` to inspect one saved report before export, archive, share, or Knowledge promotion. The visual-report contract names required sections, citation/source-map acceptance criteria, report save, review-packet, and ZIP archive routes so richer rendering stays tied to the same reviewed artifacts. Use Agent Workspace -> Documents & Compare when a document needs a versioned markdown draft, review comments, AI suggestion review, review status, reviewer-ready document artifact export, chronological review packet timeline with stale-preset attention, guided review packet progress/routes/backtracking/final archive review/refreshed-preset lineage/share handoff, reviewer-readiness preflight for unresolved comments/suggestions/source artifacts/comparison reveal/route decisions/handoff evidence, inline readiness badges at export/archive/apply points, packet-default prefill for the next export/handoff/archive/apply/leave-unchanged/save-preset/share form, a saved packet preset for recurring evidence ids with freshness checks before reuse and confirmed refresh when newer matching evidence exists, saved artifact attachment or insertion, single-artifact export, multi-artifact package directory or ZIP archive export, prompt context, source checks, generated media artifacts, reviewed artifact-to-Knowledge promotion, saved text artifact reuse in blind comparison, or a confirmed blind model comparison with local review, side-by-side reviewer view, split-pane reviewer handoff diff with section jumps and recent-handoff defaults, judgment, confirmed route-decision receipts, task/document/benchmark-filtered analytics, synthesis, reviewer handoff artifacts, one-click reviewer handoff ZIP archives with matching route-decision receipt evidence, and confirmed packet share through `agent_review_packet_share` when the user wants to send an archive reference to a configured channel target. Use confirmed Agent Knowledge ingest actions when a reviewed source should become durable.
+Use Agent Workspace -> Research for read-only web research, URL inspection, visible checkpointable research run state, a read-only Research briefing queue, bounded public source-candidate search, certified live SDK/daemon browser-runner and visual-report render evidence when published, project-local source queue review, reviewed-source bundles, saved report inspection, and confirmed sourced report artifacts. Research requests do not ingest sources. The Research workspace shows browser-runner and visual-report readiness, the direct `research` run/source/report routes, a Research briefing action for `research action:"briefing"`, a Plan workflow action for `research action:"plan"`, a Public source search action for `research action:"search"`, a Browser runner readiness action for `research action:"runner"`, and a Report artifacts action for `research action:"reports"`. Use `research action:"briefing"` first when the model needs one read-only next-action queue across visible runs, source review, saved report artifacts, certified live runner/render evidence, browser readiness, and exact follow-up routes. Use `research action:"search"` for one bounded public web search that returns capture-ready source candidates plus exact confirmed `add_source` routes; pass `runId` to use an existing visible run's saved question and receive run-specific start/checkpoint follow-up routes. It does not create runs or write source records by itself. Use `research action:"runner"` for the direct browser-backed runner readiness contract and setup/fallback routes. Use `research action:"plan"` when the model needs one ordered route plan for a research request or existing run; it returns visible-run, source-collection, source-review, visual-report-save, and Knowledge-promotion steps plus browser-runner and visual-report packet contracts without performing any of them. Research run records keep the user-facing question, phase, progress, checkpoints, log tails, source ids, next steps, confirmed lifecycle routes, certified live browser-runner records with schema/version/publication/publisher/provenance/freshness-cursor/receipt evidence, redacted current URLs/logs, source/page receipt ids, and runner posture that tells the model whether browser-backed research is ready, needs setup review, or should fall back to public web/fetch routes without starting hidden background work. Research run detail and mutation outputs include next-route packets for inspect, briefing, workflow, run-bound search, source queue, checkpoint, report save, artifact inspection, and Knowledge promotion when a report artifact exists. The browser-runner contract names the required visible run controls, source-capture receipts, bounded logs, report handoff, setup routes, fallback routes, and certified read-model evidence before live browser execution is treated as ready. Source queue records keep credibility, score, report-ready source lines, source bundle handoffs, and safe routes; source detail and mutation outputs point to the next review, reject, bundle, report, mark-used, artifact inspection, or optional Knowledge promotion route without performing those effects. Saved report artifacts keep a source map, citation coverage metadata, repair hints, optional strict body-citation enforcement, optional `visualReport:true` packet sections for at-a-glance summary, evidence matrix, findings board, dated source/comparison view, open questions, next actions, and handoff checklist, and next-route packets for report inspection, artifact export/archive, Knowledge promotion, report listing, and visible run completion when `runId` is supplied. Use `research action:"report_artifact" artifactId:"..."` to inspect one saved report before export, archive, share, or Knowledge promotion. The visual-report contract names required sections, citation/source-map acceptance criteria, report save, review-packet, ZIP archive routes, and certified browser/PWA render read models with render route, redacted render URL, source-map count, citation coverage, visual sections, publication, and receipt evidence so richer rendering stays tied to the same reviewed artifacts. Use Agent Workspace -> Documents & Compare when a document needs a versioned markdown draft, review comments, AI suggestion review, review status, reviewer-ready document artifact export, chronological review packet timeline with stale-preset attention, guided review packet progress/routes/backtracking/final archive review/refreshed-preset lineage/share handoff, reviewer-readiness preflight for unresolved comments/suggestions/source artifacts/comparison reveal/route decisions/handoff evidence, inline readiness badges at export/archive/apply points, packet-default prefill for the next export/handoff/archive/apply/leave-unchanged/save-preset/share form, a saved packet preset for recurring evidence ids with freshness checks before reuse and confirmed refresh when newer matching evidence exists, saved artifact attachment or insertion, single-artifact export, multi-artifact package directory or ZIP archive export, prompt context, source checks, generated media artifacts, reviewed artifact-to-Knowledge promotion, saved text artifact reuse in blind comparison, or a confirmed blind model comparison with local review, side-by-side reviewer view, split-pane reviewer handoff diff with section jumps and recent-handoff defaults, judgment, confirmed route-decision receipts, task/document/benchmark-filtered analytics, synthesis, reviewer handoff artifacts, one-click reviewer handoff ZIP archives with matching route-decision receipt evidence, and confirmed packet share through `agent_review_packet_share` when the user wants to send an archive reference to a configured channel target. Use confirmed Agent Knowledge ingest actions when a reviewed source should become durable.
 
 Use the Artifacts area and Voice & Media workspace for images, source files, generated media, and exported sessions. Generated media returns artifact ids and metadata, not inline base64.
 
@@ -193,7 +193,9 @@ When no connected host is reachable, inspect `setup action:"item" setupItemId:"c
 
 ## Current Product Notes
 
-Agent uses the GoodVibes terminal shell, renderer, input, fullscreen workspace, command registry, and release foundation. Use `execution action:"status"` before computer-work handoffs: local read/edit/exec is the preferred route when the current workspace and permissions are sufficient, and Agent Workspace -> Work & Approvals shows local process supervision with tracked/running/completed counts, stdin/PTY/sudo parity, and Background processes / Process capabilities actions. Local shell/edit routes advertise process monitor/live tail/tool inspector supervision; first-class `execution`, `terminal`, and `process` adapters expose `execution action:"status|route|history|record|processes|process_capabilities|process|recovery"`, `terminal(command, background:true)`, and `process(action:"list|poll|wait|log|kill|write")` over the same tracked ProcessManager lifecycle. `execution action:"capabilities|doctor|parity"` now goes straight to the read-only process capability report, while `process action:"capabilities"` remains available for users already in the process lifecycle tool. Lower-level `mode:"execution_posture|execution_route|browser_control_route|background_processes|background_process|run_background_process|execution_history|execution_history_item|file_recovery|run_file_recovery"` routes remain available for compatibility and detailed inspection. The process capability report probes SDK ProcessManager methods plus daemon terminal/PTY, session-input, and credential routes so unsupported interactive features are tied to exact contract evidence instead of stale assumptions. PTY remains unsupported until a typed interactive session contract exists, and background sudo prompts are blocked in favor of visible user-supervised escalation. `setup action:"item" setupItemId:"sudo-execution-posture"` exposes SUDO_PASSWORD presence only, `~/.goodvibes/.env` guidance, blocked background sudo/stdin password routes, and the foreground shell route without reading or returning raw password values. `setup action:"status"` also exposes connected-host setup repair cards with live service probe evidence, token-safe auth posture, exact pairing route ids, confirmed local token provisioning, status, service posture, recommended diagnostic/status routes, and confirmed service install/start/restart routes that stay inspect-first until service status proves need, plus browser/desktop-control readiness with ready, attention, or setup-needed state, workflow cards, setup checklist, fallback routes, MCP review routes, and `computer action:"plan"` for selecting a browser navigation, screenshot/observation, or desktop-control workflow before any trusted live-control tool is invoked. Visible subagents stay serial-by-default unless independent work materially helps the user. `agent_harness mode:"agent_orchestration"` exposes the live Agent manager, managed multi-agent plan milestones, per-agent plan cards, linked work-plan receipts, closeout review/update routes, remote-runner contracts/artifact trails, auto-attached remote artifact review routes matched by runner id, spawn/batch-spawn decision cards, templates, and exact `agent` list/inspect/message/wait/cancel routes; `mode:"agent_orchestration_agent"` inspects one visible agent record with its plan card. Approved visible work-plan items can be converted into visible agents through confirmed `agent_work_plan action:"dispatch_agents"`; the route previews without spawning, then calls first-class `agent` spawn or batch-spawn, writes linked-agent receipts back to the plan, and returns next routes for orchestration, work-plan detail, agent inspect/wait/message/cancel, and closeout. Delegation is reserved for isolation, parallelism, remote execution, separate worktrees, or user-requested delegated review. `delegation action:"status|routes"` exposes local-first, TUI handoff, delegated-review, remote-inspection, and hidden-fanout-blocked decision cards; `delegation action:"route"` rows show required fields, success evidence, status routes, and recovery routes, while lower-level `agent_harness mode:"delegation_posture|delegation_route"` remains available for detailed compatibility inspection. The confirmed `/delegate` and Agent Workspace handoff form preserve the original ask plus delegation reason, success criteria, workspace/worktree hint, priority, and explicit review intent. The active autonomy policy is visible autonomy: long-running work must have a user-readable task, status/progress, cancellation route, success criteria, and confirmation gates for external or daemon-mutating effects. Use `autonomy action:"intake"` to turn an ongoing-work request into the safest visible route and missing fields; webhook/event-trigger requests expose trigger workflow posture and route applicable incoming watcher setup to the published `watchers.create` operator method, with trusted source/scope, task or run target, success criteria, `confirm:true`, and `explicitUserRequest` required. Confirmed autonomous schedule creation uses `schedule action:"create"`, and confirmed existing-schedule edits use `schedule action:"edit"` with read-only current-state diffs before confirmation. Inspect current autonomy cards with `autonomy action:"queue"` or one card with `action:"item"`; lower-level `agent_harness mode:"autonomy_intake|autonomy_queue|autonomy_queue_item"` remains available for detailed compatibility inspection. Research runs, connected-host tasks, approvals, automation runs, schedules, and delegated subagents surface live records or exact orchestration routes with progress/status, source ids, next steps, log tails when available, task retry/output/correlation diagnostics, bounded redacted host task output route/preview descriptors, automation telemetry/delivery/route diagnostics, normalized available/unavailable controls with reasons, and exact inspect/checkpoint/pause/resume/cancel/approve/deny/retry/run/edit/enable/disable/delete routes where the owning surface supports them. Schedule records also expose pause/resume aliases over daemon enable/disable lifecycle routes so the queue speaks in user intent instead of scheduler internals. Connected-host task cancel/retry stays on exact confirmed `agent_operator_method` routes, while `/tasks` remains inspection-only.
+Agent uses the GoodVibes terminal shell, renderer, input, fullscreen workspace, command registry, and release foundation. Use `execution action:"status"` before computer-work handoffs: local read/edit/exec is the preferred route when the current workspace and permissions are sufficient, and Agent Workspace -> Work & Approvals shows local process supervision with tracked/running/completed counts, stdin/PTY/sudo parity, and Background processes / Process capabilities actions. Local shell/edit routes advertise process monitor/live tail/tool inspector supervision; first-class `execution`, `terminal`, and `process` adapters expose `execution action:"status|route|history|record|processes|process_capabilities|process|recovery"`, `terminal(command, background:true)`, and `process(action:"list|poll|wait|log|kill|write")` over the same tracked ProcessManager lifecycle. `execution action:"capabilities|doctor|parity"` now goes straight to the read-only process capability report, while `process action:"capabilities"` remains available for users already in the process lifecycle tool. Lower-level `mode:"execution_posture|execution_route|browser_control_route|background_processes|background_process|run_background_process|execution_history|execution_history_item|file_recovery|run_file_recovery"` routes remain available for compatibility and detailed inspection. The process capability report probes SDK ProcessManager methods plus daemon terminal/PTY, session-input, and credential routes so unsupported interactive features are tied to exact contract evidence instead of stale assumptions. PTY remains unsupported until a typed interactive session contract exists, and background sudo prompts are blocked in favor of visible user-supervised escalation. `setup action:"item" setupItemId:"sudo-execution-posture"` exposes SUDO_PASSWORD presence only, `~/.goodvibes/.env` guidance, blocked background sudo/stdin password routes, and the foreground shell route without reading or returning raw password values. `setup action:"status"` also exposes connected-host setup repair cards with live service probe evidence, token-safe auth posture, exact pairing route ids, confirmed local token provisioning, status, service posture, recommended diagnostic/status routes, and confirmed service install/start/restart routes that stay inspect-first until service status proves need, plus browser/desktop-control readiness with ready, attention, or setup-needed state, workflow cards, setup checklist, fallback routes, MCP review routes, and `computer action:"plan"` for selecting a browser navigation, screenshot/observation, or desktop-control workflow before any trusted live-control tool is invoked. Visible subagents stay serial-by-default unless independent work materially helps the user. `agent_harness mode:"agent_orchestration"` exposes the live Agent manager, managed multi-agent plan milestones, per-agent plan cards, linked work-plan receipts, closeout review/update routes, remote-runner contracts/artifact trails, certified daemon/SDK live capture/export/closeout outcome records, certified workspace/worktree isolation evidence with schema/version/publication/publisher/provenance/freshness-cursor/receipt metadata and missing-signal surfacing, auto-attached remote artifact review routes matched by runner id, spawn/batch-spawn decision cards, templates, and exact `agent` list/inspect/message/wait/cancel routes; `mode:"agent_orchestration_agent"` inspects one visible agent record with its plan card. Approved visible work-plan items can be converted into visible agents through confirmed `agent_work_plan action:"dispatch_agents"`; the route previews without spawning, then calls first-class `agent` spawn or batch-spawn, writes linked-agent receipts back to the plan, and returns next routes for orchestration, work-plan detail, agent inspect/wait/message/cancel, and closeout. Delegation is reserved for isolation, parallelism, remote execution, separate worktrees, or user-requested delegated review. `delegation action:"status|routes"` exposes local-first, TUI handoff, delegated-review, remote-inspection, and hidden-fanout-blocked decision cards; `delegation action:"route"` rows show required fields, success evidence, status routes, and recovery routes, while lower-level `agent_harness mode:"delegation_posture|delegation_route"` remains available for detailed compatibility inspection. The confirmed `/delegate` and Agent Workspace handoff form preserve the original ask plus delegation reason, success criteria, workspace/worktree hint, priority, and explicit review intent. The active autonomy policy is visible autonomy: long-running work must have a user-readable task, status/progress, cancellation route, success criteria, and confirmation gates for external or daemon-mutating effects. Use `autonomy action:"intake"` to turn an ongoing-work request into the safest visible route and missing fields; webhook/event-trigger requests expose trigger workflow posture and route applicable incoming watcher setup to the published `watchers.create` operator method, with trusted source/scope, task or run target, success criteria, `confirm:true`, and `explicitUserRequest` required. Confirmed autonomous schedule creation uses `schedule action:"create"`, and confirmed existing-schedule edits use `schedule action:"edit"` with read-only current-state diffs before confirmation. Inspect current autonomy cards with `autonomy action:"queue"` or one card with `action:"item"`; lower-level `agent_harness mode:"autonomy_intake|autonomy_queue|autonomy_queue_item"` remains available for detailed compatibility inspection. Research runs, connected-host tasks, approvals, automation runs, schedules, and delegated subagents surface live records or exact orchestration routes with progress/status, source ids, next steps, log tails when available, task retry/output/correlation diagnostics, bounded redacted host task output route/preview descriptors, automation telemetry/delivery/route diagnostics, normalized available/unavailable controls with reasons, and exact inspect/checkpoint/pause/resume/cancel/approve/deny/retry/run/edit/enable/disable/delete routes where the owning surface supports them. Schedule records also expose pause/resume aliases over daemon enable/disable lifecycle routes so the queue speaks in user intent instead of scheduler internals. Connected-host task cancel/retry stays on exact confirmed `agent_operator_method` routes, while `/tasks` remains inspection-only.
+
+The autonomy queue also consumes SDK/daemon watcher run/source read models when they are published, including watcher run history, automation watcher runs, Gmail/email provider sources, bounded redacted watcher output chunks, source/checkpoint/correlation diagnostics, read-only provider-source inspect/refresh controls, and exact confirmed watcher controls only when the owning host publishes those routes.
 
 The preferred model-facing schedule path is now `schedule action:"list|create|remind|edit|run|pause|resume|delete"`. The lower-level `agent_autonomy_schedule`, `agent_reminder_schedule`, `agent_schedule_edit`, and `agent_operator_action` routes remain available for exact diagnostics and compatibility.
 

package/docs/tools-and-commands.md

@@ -8,7 +8,7 @@ GoodVibes Agent is a TUI-first operator assistant. The workspace is the primary
 - Agent Knowledge uses only `/api/goodvibes-agent/knowledge/*`.
 - Agent does not query default knowledge or other product knowledge spaces.
 - Connected-host lifecycle is external. Agent reports and uses public routes, but does not start, stop, restart, install, expose, or mutate the host listener.
-- Local read/edit/exec is available for explicit work in the current Agent workspace when permissions are sufficient. `execution action:"status|route"` exposes process monitor, live tail, tool inspector, browser/desktop ready-attention-setup state, workflow cards, setup checklists, fallback routes, sudo posture, tracked process routes, and delegation decision cards for local work. `execution action:"history|record|processes|process|recovery"` gives direct read-only access to activity cards, exact records, tracked local processes, bounded redacted output, and file edit recovery. First-class `terminal` and `process` adapters expose the expected `terminal(command, background:true)` and `process(action:"list|poll|wait|log|kill|write")` UX over the same tracked ProcessManager lifecycle. Lower-level `execution_posture`, `execution_route`, `background_processes`, `background_process`, `run_background_process`, `execution_history`, `execution_history_item`, `file_recovery`, and `run_file_recovery` modes remain available for detailed compatibility inspection and confirmed recovery/lifecycle effects. Visible Agent subagents stay serial-by-default unless parallelism helps the user; `agent_orchestration` and `agent_orchestration_agent` expose live Agent state, managed multi-agent plan cards, work-plan links, dispatch receipts, closeout review cards, remote-runner evidence, auto-attached remote artifact review routes, spawn/batch-spawn policy, and safe first-class `agent` control routes, while confirmed `agent_work_plan action:"dispatch_agents"` converts approved plan items into visible agent jobs with saved receipts. Delegation is for isolation, parallelism, remote execution, separate worktrees, or user-requested delegated review; `delegation action:"status|routes|route"` exposes local-first, TUI handoff, delegated-review, remote-inspection, and hidden-fanout-blocked lanes with required fields, success evidence, status routes, and recovery routes.
+- Local read/edit/exec is available for explicit work in the current Agent workspace when permissions are sufficient. `execution action:"status|route"` exposes process monitor, live tail, tool inspector, browser/desktop ready-attention-setup state, workflow cards, setup checklists, fallback routes, sudo posture, tracked process routes, and delegation decision cards for local work. `execution action:"history|record|processes|process|recovery"` gives direct read-only access to activity cards, exact records, tracked local processes, bounded redacted output, and file edit recovery. First-class `terminal` and `process` adapters expose the expected `terminal(command, background:true)` and `process(action:"list|poll|wait|log|kill|write")` UX over the same tracked ProcessManager lifecycle. Lower-level `execution_posture`, `execution_route`, `background_processes`, `background_process`, `run_background_process`, `execution_history`, `execution_history_item`, `file_recovery`, and `run_file_recovery` modes remain available for detailed compatibility inspection and confirmed recovery/lifecycle effects. Visible Agent subagents stay serial-by-default unless parallelism helps the user; `agent_orchestration` and `agent_orchestration_agent` expose live Agent state, managed multi-agent plan cards, work-plan links, dispatch receipts, closeout review cards, remote-runner evidence, certified daemon/SDK live remote capture/export/closeout outcome records, certified workspace/worktree isolation evidence with schema/version/publication/publisher/provenance/freshness-cursor/receipt metadata and missing-signal surfacing, auto-attached remote artifact review routes, spawn/batch-spawn policy, and safe first-class `agent` control routes, while confirmed `agent_work_plan action:"dispatch_agents"` converts approved plan items into visible agent jobs with saved receipts. Delegation is for isolation, parallelism, remote execution, separate worktrees, or user-requested delegated review; `delegation action:"status|routes|route"` exposes local-first, TUI handoff, delegated-review, remote-inspection, and hidden-fanout-blocked lanes with required fields, success evidence, status routes, and recovery routes.
 - External delivery, notifications, reminders, media generation, setting writes, keybinding writes, UI routing, slash-command execution, workspace-action execution, local destructive changes, and connected-host operator actions require explicit user request and confirmation.
 - Autonomous scheduled work uses the first-class `schedule` adapter: `schedule action:"list|create|remind|edit|run|pause|resume|delete"`. Creation still requires an explicit task or reminder, cadence, success criteria for autonomous work, user request provenance, and confirmation.
 
@@ -88,12 +88,12 @@ Discovery modes:
 | `channels action:"status|channel|setup|triage|deliveries"`, `notifications` | Channel readiness, ordered setup guide state, blockers/retry triage, redacted confirmed-send receipts, and redacted notification targets. |
 | `context action:"files|file"` | Secret-scanned `.hermes.md`, `HERMES.md`, `AGENTS.md`, `CLAUDE.md`, `HERMES_HOME/SOUL.md`, `.cursorrules`, and `.cursor/rules/*.mdc` files, including target-aware subdirectory context. |
 | `context action:"prompt|receipts|receipt"` | Applied prompt composition order, recent durable receipt ids, exact receipt/turn/outcome filters, sanitized turn outcomes, selected context records, suppressed records, prompt previews on request, and approximate token budget; the same recent receipt outcomes are summarized in Agent Workspace -> Local Context with exact drill-in routes. |
-| `memory action:"status|provider|curator|candidate|list|search|get"` plus lower-level `memory_posture`, `memory_provider` | Agent-local memory counts, prompt-active recall, vector stats, embedding-provider doctor warnings, provider inspection, curator review queues, direct memory record lookup/search, and external-memory setup contract maps for Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, and Supermemory, including provider-specific next routes, missing setup/status/read/write/sync checks, and required receipt fields without claiming unpublished SDK/daemon provider records. |
-| `agent_orchestration` | Live visible Agent records, managed multi-agent plan cards with milestones, work-plan links, dispatch receipt counts, closeout cards, remote-runner evidence, auto-attached remote artifact review routes, serial-by-default policy, approved work-plan dispatch route, spawn/batch-spawn decision cards, templates, and first-class `agent` routes for list/inspect/message/wait/cancel. |
-| `models action:"status|route|local|providers|provider|smoke"` plus lower-level `provider_accounts`, `model_routing`, `model_route`, `run_local_model_smoke` | Provider auth, provider/model route posture, visible route-readiness inspection, readiness scores, hardware-scored local model cookbook with setup plans, exact local endpoint inspection, confirmed local model-list smoke checks, models-endpoint smoke criteria and refresh/provider-add hints, confirmed benchmark action/history/evidence review, and compatibility detail routes. |
+| `memory action:"status|provider|curator|candidate|list|search|get"` plus lower-level `memory_posture`, `memory_provider` | Agent-local memory counts, prompt-active recall, vector stats, embedding-provider doctor warnings, provider inspection, curator review queues, direct memory record lookup/search, and external-memory setup contract maps for Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, and daemon-published similar backends, including provider-specific next routes, certified schema/version/publication/publisher/provenance checks, setup/status/read/write/sync/forget checks, required receipt fields, certified artifact evidence, and sanitized certified live read-model records when the SDK/daemon publishes them. |
+| `agent_orchestration` | Live visible Agent records, managed multi-agent plan cards with milestones, work-plan links, dispatch receipt counts, closeout cards, remote-runner contract/artifact evidence, certified daemon/SDK live capture/export/closeout outcome records, certified workspace/worktree isolation evidence with schema/version/publication/publisher/provenance/freshness-cursor/receipt metadata and missing-signal surfacing, auto-attached remote artifact review routes, serial-by-default policy, approved work-plan dispatch route, spawn/batch-spawn decision cards, templates, and first-class `agent` routes for list/inspect/message/wait/cancel. |
+| `models action:"status|route|local|providers|provider|smoke"` plus lower-level `provider_accounts`, `model_routing`, `model_route`, `run_local_model_smoke` | Provider auth, provider/model route posture, visible route-readiness inspection, readiness scores backed by exact route-level provider-health records when published, hardware-scored local model cookbook with setup plans, exact local endpoint inspection, certified daemon-published local serving diagnostics with schema/provenance/publication and host-published start/repair routes when available, confirmed local model-list smoke checks, models-endpoint smoke criteria and refresh/provider-add hints, confirmed benchmark action/history/evidence review, and compatibility detail routes. |
 | `execution action:"status|route|history|record|processes|process_capabilities|process|recovery"`, `terminal`, `process`, plus lower-level execution harness modes | Local-vs-delegated execution routing, tracked process inspection, interactive PTY/stdin/sudo posture, direct process parity/doctor reports, first-class background-process start/manage adapters, process substrate probes with future stdin-write dispatch, grouped execution activity cards with redacted records, and file edit recovery. |
-| `personal_ops action:"briefing|status|queue|intake|lane|read"` plus lower-level `personal_ops_briefing`, `personal_ops`, `personal_ops_queue`, `personal_ops_intake`, `personal_ops_lane`, `run_personal_ops_read` | Read-only daily briefing plan across inbox, agenda, tasks, reminders, routines, delivery, notes, and autonomy queue; read-only saved inbox/calendar review queue with refresh routes and follow-up boundaries; inbox/calendar connector readiness, request intake that chooses the safest lane/route/fields/confirmation boundary, classified MCP read/write tool hints, schema-derived operation records with fresh-read routes, triage/draft/agenda/conflict workflow cards, ordered connector-read/local-compose/confirmed-effect execution plans, confirmed read-only MCP inbox/calendar reads with bounded redacted output, normalized review cards, optional saved redacted review-card artifacts surfaced as redacted inbox thread/calendar event queue records with artifact inspect routes, freshness status, confirmed refresh routes when a matching read connector is ready, local draft/reminder follow-up routes, and confirmed provider-effect boundaries, matching MCP setup routes, and live Agent-owned note, routine, schedule-receipt, and delivery records. |
-| `autonomy action:"intake|queue|item|status"` | Ongoing-work route selection, visible autonomous work owners, schedule/watcher trigger posture, watcher receipt criteria, source-owned watcher evidence contracts, status, live records, log tails, task/run diagnostics, host task output routes/previews, inspect routes, and normalized checkpoint/pause/resume/cancel/recovery controls. Lower-level `autonomy_intake`, `autonomy_queue`, and `autonomy_queue_item` modes remain available for detailed compatibility inspection. |
+| `personal_ops action:"briefing|status|queue|intake|lane|read"` plus lower-level `personal_ops_briefing`, `personal_ops`, `personal_ops_queue`, `personal_ops_intake`, `personal_ops_lane`, `run_personal_ops_read` | Read-only daily briefing plan across inbox, agenda, tasks, reminders, routines, delivery, notes, and autonomy queue; read-only saved inbox/calendar review queue with refresh routes, daemon/SDK provider read-model records, and follow-up boundaries; inbox/calendar connector readiness, request intake that chooses the safest lane/route/fields/confirmation boundary, classified MCP read/write tool hints, schema-derived operation records with fresh-read routes, triage/draft/agenda/conflict workflow cards, ordered connector-read/local-compose/confirmed-effect execution plans, confirmed read-only MCP inbox/calendar reads with bounded redacted output, normalized review cards, optional saved redacted review-card artifacts surfaced as redacted inbox thread/calendar event queue records with artifact inspect routes, freshness status, confirmed refresh routes when a matching read connector is ready, certified fresh provider-backed thread/event/task/reminder records with durable ids, labels, redacted snippets/notes, agenda windows, conflict signals, due times, cadence, delivery targets, source paths, schema/version/publication/publisher/provenance/receipt evidence, read-only inspect routes, local draft/reminder follow-up routes, certified provider-effect receipts for inbox/calendar/task/reminder outcomes, and confirmed provider-effect boundaries only when matching routes are published, matching MCP setup routes, and live Agent-owned note, routine, schedule-receipt, and delivery records. |
+| `autonomy action:"intake|queue|item|status"` | Ongoing-work route selection, visible autonomous work owners, schedule/watcher trigger posture, watcher receipt criteria, source-owned watcher evidence contracts, status, live task/approval/automation/schedule/watcher records, log tails, task/run diagnostics, host task and watcher output routes/previews, provider-source inspect/refresh controls, inspect routes, and normalized checkpoint/pause/resume/cancel/recovery controls. Lower-level `autonomy_intake`, `autonomy_queue`, and `autonomy_queue_item` modes remain available for detailed compatibility inspection. |
 | `memory action:"curator|candidate"` plus lower-level `learning_curator`, `learning_candidate` | Score-driven prompt plan, ranked local memory, note, persona, skill, bundle, routine, VIBE.md personality health, duplicate-consolidation batch review, completed-work, completed-research, and saved-session review/proposal candidates. |
 | `document_ops`, `document_ops_lane` | Documents, review packet timeline, review packet wizard, packet presets/defaults/freshness, reviewer-readiness checks, uploads, exports, sources, artifact browse/promotion, media artifacts, and blind model comparison. |
 | `mcp_servers`, `setup_posture`, `setup_repair`, `pairing_posture`, `delegation action:"status|routes|route"` | MCP, first-run setup wizard with direct `setup action:"status|item|repair|checkpoint|token|smoke|finish"` route hints, progress/current-step/checkpoint/backtracking routes, checkpoint auto-advance evidence, repeated-smoke-blocker focus, setup closeout decisions, read-only repair decisions for token/status/bootstrap/lifecycle/no-action routes, setup plan with probe-fed connected-host repair/auth cards, service lifecycle receipt gates, service repair success criteria, certified receipt outcomes, exact service lifecycle decisions, sudo execution posture, primary handoffs for actionable setup rows, confirmed local token provisioning, token-safe install smoke checks, confirmed setup smoke execution, saved redacted smoke evidence artifacts with history/trend surfacing, local model readiness with endpoint smoke-test follow-through, pairing/device capability posture, and build-delegation posture. Lower-level `delegation_posture` and `delegation_route` remain compatibility routes. |
@@ -129,7 +129,7 @@ Effect modes:
 
 | Mode | Effect |
 | --- | --- |
-| `setup` tool | Preferred first-run setup route: `action:"status|item|repair|checkpoint"` reads, and `action:"save_checkpoint|clear_checkpoint|token|smoke|finish|import_settings"` delegates to existing confirmed setup effects. |
+| `setup` tool | Preferred first-run setup route: `action:"status|item|repair|checkpoint"` reads, including setup wizard closeout plus saved/artifact/live-read-model/ordered-event-stream receipt evidence; `action:"save_checkpoint|clear_checkpoint|token|smoke|finish|import_settings"` delegates to existing confirmed setup effects. |
 | `workspace action:"run"` | Executes one resolved workspace action through the same editor, command, or local route as the TUI; `actionId:"onboarding-apply-close"` is the confirmed setup closeout marker write. |
 | `workspace action:"run_command"` | Executes one resolved slash command through the shared command registry. |
 | `provision_connected_host_token` | Creates or repairs the local canonical connected-host token after confirmation without returning the raw token. |
@@ -151,7 +151,7 @@ Registered model tool definitions are compact by default. Tool descriptions use
 
 `workspace action:"panels"` returns compact built-in panel rows with workspace route metadata and a short `modelRoute` for visible navigation or matching workspace operation. `workspace action:"panel"` inspection adds policy detail and current open/focus state.
 
-Use `computer action:"browser"` for the connected browser cockpit/PWA readiness summary and `computer action:"open_browser" confirm:true explicitUserRequest:"..."` for the visible browser handoff. Use `computer action:"plan" query:"take a screenshot"` to choose the safest browser navigation, screenshot/observation, or desktop-control workflow before invoking any live-control tool; it returns setup/review/fallback routes plus exact tool or MCP-server inspection routes when configured. Use `computer action:"control|setup|mcp"` for browser/desktop control posture, repair routes, and trusted tool/server discovery. `workspace action:"surfaces|surface|open"` is the normal visible UI route; lower-level `browser_control_route`, `ui_surfaces`, and `ui_surface` remain detailed compatibility routes. The connected browser cockpit/PWA is `surfaceId:"connected-browser-cockpit"`; it resolves the configured connected-host web URL, opens only through confirmed `computer action:"open_browser"` or `workspace action:"open"`, returns service/web setup routes when disabled, and reports workspace category coverage, mobile/PWA controls, Agent onboarding marker status, and the currently unpublished browser/PWA first-run receipt contract.
+Use `computer action:"browser"` for the connected browser cockpit/PWA readiness summary and `computer action:"open_browser" confirm:true explicitUserRequest:"..."` for the visible browser handoff. Use `computer action:"plan" query:"take a screenshot"` to choose the safest browser navigation, screenshot/observation, or desktop-control workflow before invoking any live-control tool; it returns setup/review/fallback routes plus exact tool or MCP-server inspection routes when configured. Use `computer action:"control|setup|mcp"` for browser/desktop control posture, repair routes, and trusted tool/server discovery. `workspace action:"surfaces|surface|open"` is the normal visible UI route; lower-level `browser_control_route`, `ui_surfaces`, and `ui_surface` remain detailed compatibility routes. The connected browser cockpit/PWA is `surfaceId:"connected-browser-cockpit"`; it resolves the configured connected-host web URL, opens only through confirmed `computer action:"open_browser"` or `workspace action:"open"`, returns service/web setup routes when disabled, and reports workspace category coverage, mobile/PWA controls, Agent onboarding marker status, and browser/PWA first-run evidence. Certified SDK/daemon browser/PWA category-route read models can make every Agent workspace category `browser-native-ready` only when they include schema/version/publication/publisher/provenance/freshness-cursor/receipt metadata, exact inspect/open routes, and mobile/touch evidence. Certified browser/PWA first-run receipts add manifest, service-worker, install, and offline evidence with redacted URLs and summaries. Start/setup readiness still consumes the receipt from saved durable artifacts or live SDK/daemon setup read models when published, and keeps the receipt gap visible when neither source is present.
 
 Execution routes:
 
@@ -162,7 +162,7 @@ Execution routes:
 - Runtime prompt context applies safe VIBE.md files, safe project context files, and only reviewed, high-confidence memory plus reviewed setup-ready behavior. Blocked or truncated VIBE.md/context files and enabled but unreviewed, stale, low-confidence, or setup-blocked local behavior are surfaced as suppressed review work. Prompt builds write durable receipts with ids, turn/source/model/provider, selected and suppressed record refs, segment counts, prompt hash, size, timestamp, and sanitized completed/error/cancelled outcome without storing raw prompt or response text; Agent Workspace -> Local Context shows the compact receipt outcome timeline, exact latest-receipt route, and outcome filter routes for users. Use `context action:"prompt|receipts|receipt"` for current applied order, recent receipt ids, `receiptId`/`turnId`/`outcomeStatus` filters, turn outcomes, selected records, suppressed records, and approximate token budget before relying on persistent context; use setup, project context inspection, the Memory -> Prompt plan action, or the learning curator to fix suppressed work.
 - Read-only learning review uses `memory action:"curator"` and `memory action:"candidate"`; the curator returns a prompt plan with prompt-active records, suppressed review/setup/low-confidence/personality/consolidation counts, proposal queues, consolidation queues, usefulness/freshness/source-quality/risk ordering rules, and exact routes before durable context expands. Duplicate-consolidation candidates expose survivor ids, visible field diffs, low-level update/stale/delete/rollback routes, and first-class `agent_learning_consolidation` preview/merge/stale/delete/rollback/recreate phase routes. Merge and stale write durable receipts with rollback routes, delete refuses records that have not already been staged stale, and post-delete receipts preserve snapshots plus exact-id recreate guidance. Confirmed recreate is separate from rollback and refuses when current records would force a different id. Reviewed-note, completed-work, completed-research, and saved-session memory/behavior proposals reuse selected-note promotion, memory-create, or learned-behavior capture routes. Non-consolidation writes stay on `agent_local_registry` or visible workspace actions.
 - Agent document draft browse/show/create/revise/review/comment/suggest/accept-suggestion/reject-suggestion/artifact-insert/export dispatches through `agent_documents`; export artifacts include reviewer-ready comment and suggestion summaries. Reviewer-readiness checks are visible through Agent Workspace -> Documents & Compare -> Review readiness preflight and read-only through `agent_harness mode:"document_ops"` or `mode:"document_ops_lane" laneId:"reviewer_readiness"`; they return exact routes for resolving comments, accepting/rejecting suggestions, attaching evidence, revealing comparisons, applying or leaving model-route decisions, and repairing handoff evidence before export/archive/apply. The review packet wizard is visible through Agent Workspace -> Documents & Compare -> Review packet wizard and read-only through `mode:"document_ops_lane" laneId:"review_packet_wizard"`; it reports six-step progress, the current user/model route, backtracking routes, refreshed-preset lineage when a packet preset was repaired, final archive review guidance, and the confirmed share route. Agent Workspace -> Documents & Compare -> Save packet preset and `agent_review_packet_presets mode:"save"` store one reusable local packet preset artifact with document/export/comparison/judgment/route-decision/handoff/archive/related artifact ids; `mode:"list"` and `mode:"show"` inspect presets, flag missing or superseded saved ids, and recommend newer matching reuse routes when metadata is sufficient, without mutation. Agent Workspace -> Documents & Compare -> Refresh packet preset and `mode:"refresh"` save a new local preset artifact from those freshness recommendations after confirmation, preserving the source preset for audit history and never mutating documents, model routes, handoffs, or archives. Agent Workspace -> Documents & Compare -> Share review packet and `agent_review_packet_share` validate one saved handoff archive artifact, preview the delivery target and packet evidence ids, and send only a plain-text archive reference after explicit confirmation; ZIP bytes still move through `agent_artifacts mode:"export"` or package/archive routes. `agent_model_compare mode:"apply"` saves an apply-winner route-decision receipt after a confirmed route update, while `mode:"routeDecision" decision:"left-unchanged"` saves a receipt without changing the selected model; `mode:"handoffArchive"` carries matching route-decision receipt artifacts into the ZIP, README, archive metadata, and redacted manifest. Review packet defaults use the latest document/export/comparison/judgment/route-decision/handoff evidence, falling back to saved preset metadata only when live packet evidence is missing, to prefill document export, compare handoff/archive, winner-apply, leave-unchanged decision, save-preset, and share forms while preserving editable fields and confirmation gates.
-- Start deep research routing with `research action:"briefing"` when the model needs one read-only next-action queue across visible runs, source review, saved report artifacts, browser readiness, and exact follow-up routes. Use `research action:"plan"` when it needs one ordered route plan across visible run state, public web/fetch or browser posture, browser-runner contract readiness, source capture/review, visual-report packet saving, and optional Knowledge promotion. Use `research action:"search"` for bounded public web research that returns capture-ready source candidates and exact confirmed `add_source` routes without writing local source state; pass `runId` to use the visible run's saved question and receive run-specific start/checkpoint follow-up routes. Use `research action:"runner"` for the direct browser-backed runner readiness contract without the full workflow plan. The browser-runner contract names setup/fallback routes, visible run controls, source-capture receipts, bounded logs, and report handoff before live browser-backed execution is treated as ready. The visual-report contract names report sections, source-map/citation acceptance criteria, `research action:"report" visualReport:true` save routes, review-packet, and ZIP archive routes without saving anything by itself. Use `research action:"reports"` to list saved sourced report artifacts and `research action:"report_artifact" artifactId:"..."` to preview one report packet before export, archive, share, or Knowledge promotion. Visible research run creation/checkpoint/pause/resume/cancel/complete, log-tail inspection, source capture/review/bundles, and confirmed sourced report saves all have direct `research` actions; run detail and mutation outputs include next-route packets for inspect, briefing, workflow, run-bound search, source queue, checkpoint, report save, artifact inspection, and Knowledge promotion when a report artifact exists. Source detail and mutation outputs include next-route packets for review/reject, bundle, sourced report save, mark-used, report artifact inspection, and optional URL/artifact Knowledge promotion while preserving the separate confirmation gate. Confirmed report saves include next-route packets for high-level report inspection, artifact export/archive, Knowledge promotion, report listing, and visible run completion when `runId` is supplied. Lower-level `agent_research_runs`, `agent_research_sources`, and `agent_research_report` remain available for detailed compatibility routes.
+- Start deep research routing with `research action:"briefing"` when the model needs one read-only next-action queue across visible runs, source review, saved report artifacts, certified live SDK/daemon runner/render evidence, browser readiness, and exact follow-up routes. Use `research action:"plan"` when it needs one ordered route plan across visible run state, public web/fetch or browser posture, browser-runner contract readiness, source capture/review, visual-report packet saving, and optional Knowledge promotion. Use `research action:"search"` for bounded public web research that returns capture-ready source candidates and exact confirmed `add_source` routes without writing local source state; pass `runId` to use the visible run's saved question and receive run-specific start/checkpoint follow-up routes. Use `research action:"runner"` for the direct browser-backed runner readiness contract without the full workflow plan. The browser-runner contract names setup/fallback routes, visible run controls, source-capture receipts, bounded logs, report handoff, and certified live runner read-model fields before live browser-backed execution is treated as ready. The visual-report contract names report sections, source-map/citation acceptance criteria, certified browser/PWA render evidence, `research action:"report" visualReport:true` save routes, review-packet, and ZIP archive routes without saving anything by itself. Use `research action:"reports"` to list saved sourced report artifacts and `research action:"report_artifact" artifactId:"..."` to preview one report packet before export, archive, share, or Knowledge promotion. Visible research run creation/checkpoint/pause/resume/cancel/complete, log-tail inspection, source capture/review/bundles, certified live browser-runner/source-receipt evidence, certified visual-report render evidence, and confirmed sourced report saves all have direct `research` actions; run detail and mutation outputs include next-route packets for inspect, briefing, workflow, run-bound search, source queue, checkpoint, report save, artifact inspection, and Knowledge promotion when a report artifact exists. Source detail and mutation outputs include next-route packets for review/reject, bundle, sourced report save, mark-used, report artifact inspection, and optional URL/artifact Knowledge promotion while preserving the separate confirmation gate. Confirmed report saves include next-route packets for high-level report inspection, artifact export/archive, Knowledge promotion, report listing, and visible run completion when `runId` is supplied. Lower-level `agent_research_runs`, `agent_research_sources`, and `agent_research_report` remain available for detailed compatibility routes.
 - Confirmed Agent Knowledge URL/file/artifact-id/bookmark/browser-history/connector ingest dispatches through `agent_knowledge_ingest`.
 - Command-backed editors dispatch through `workspace action:"run_command"`.
 - Learned-behavior and profile creation use the Agent-local or slash-command route.
@@ -173,6 +173,8 @@ Execution routes:
 
 Use `execution action:"processes"` for a compact list of tracked local processes, `execution action:"process" processId:"..."` for one process with bounded redacted stdout/stderr tails plus byte/count/truncation metadata, and `execution action:"capabilities"` or `action:"process_capabilities"` for the read-only terminal/process/PTY/sudo parity report. Use `terminal` for the simple model-facing start path: `terminal command:"pytest -v tests/" background:true confirm:true explicitUserRequest:"..."`. Use `process` for the simple lifecycle path: `process action:"list"`, `process action:"poll" session_id:"..."`, `process action:"log" session_id:"..."`, `process action:"wait" session_id:"..." confirm:true explicitUserRequest:"..."`, `process action:"kill" session_id:"..." confirm:true explicitUserRequest:"..."`, `process action:"write" session_id:"..." data:"..." confirm:true explicitUserRequest:"..."`, and `process action:"capabilities"`.
 
+When the SDK or daemon publishes certified interactive runtime read models, `execution action:"status"` and `process action:"capabilities"` also show live process output chunks, typed PTY session routes, sudo credential mediation routes, and browser/desktop command receipts with schema/version/publication/publisher/provenance evidence, bounded redacted output, exact confirmed control routes, and missing certification signals. Certified browser/desktop receipts can make `computer action:"plan|control"` ready through the published daemon route; uncertified or absent records remain setup/review posture.
+
 Use lower-level `background_processes` and `background_process` only when detailed compatibility route inspection is needed, and confirmed `run_background_process` when the lower-level harness lifecycle route is needed. The route accepts process-tool wording: `start`, `wait`, `stop`, `kill`, `poll`, `log`, and `write`; `poll` maps to status, `log` maps to output with the same explicit truncation metadata, `kill` maps to stop, and `write` requires `confirm:true`, `explicitUserRequest`, one process id, and non-empty `data`. With the current SDK, `write` returns unsupported guidance; if the shared ProcessManager exposes a safe stdin method such as `writeInput`, Agent dispatches through that method without echoing the input back. `processId`, `processSessionId`, `sessionId`, or `session_id` all resolve the tracked process id.
 
 Foreground `exec` remains the default for tests, builds, and one-shot commands. Raw exec background flags and `bg_*` controls are blocked in Agent so long-running work has a visible process id, process monitor/live-tail routes, timeout, and cancellation path. PTY mode returns unsupported guidance until the SDK/daemon process substrate exposes a typed interactive session API. Background sudo prompts are blocked; privileged commands should stay visible and user-supervised. `setup action:"item" setupItemId:"sudo-execution-posture"` shows SUDO_PASSWORD presence only, the expected `~/.goodvibes/.env` location for future mediated support, blocked background sudo/stdin password routes, missing SDK/daemon contracts, and the foreground shell route without printing or storing raw password values.
@@ -198,7 +200,7 @@ None of those modes expose host start, stop, restart, install, expose-listener,
 
 ## Visible Autonomy
 
-Use `autonomy action:"intake"` first when the user asks for ongoing work and the safest route is not obvious. It is read-only and returns the likely route, missing fields, confirmation boundary, and trigger workflow posture for time-based wakeups/schedules, incoming webhooks/watchers, Gmail/email connector triggers, and control-plane event streams. Webhook, watcher, Gmail, or event-trigger requests now point to the published `watchers.create` contract when applicable, but watcher creation is an admin connected-host mutation: require trusted source/scope, task or run target, success criteria, `confirm:true`, and `explicitUserRequest`. The intake action also returns watcher receipt success criteria plus a read-only watcher evidence contract for SDK/daemon-owned durable run-history receipts, provider source records, redacted event payload descriptors, and autonomy queue correlation. Confirmed `agent_operator_method` calls summarize `watchers.create/patch/run/start/stop/delete` receipts into certified or follow-up outcomes without exposing operator tokens. Use `schedule action:"create"` for one visible autonomous schedule, `schedule action:"remind"` for reminders, `schedule action:"edit"` for one exact schedule edit, and `schedule action:"run|pause|resume|delete"` for lifecycle controls; it forwards to the same preview, read-only current-state diff, confirmation, and connected-host routes as `agent_autonomy_schedule`, `agent_reminder_schedule`, `agent_schedule_edit`, and allowlisted `agent_operator_action`, then returns post-action next routes for schedule list, autonomy queue inspection, run, edit, pause, resume, and delete where the schedule still exists. Unconfirmed schedule and routine-promotion previews return `confirmationRoutes` so the user or model can confirm the same intent without guessing the next command. Confirmed routine schedule promotion through the workspace or `/schedule promote-routine` returns the same post-action schedule next routes. Use `autonomy action:"queue"` before creating recurring autonomous work, reminders, routine schedules, delegated work, run controls, schedule edits, approval decisions, watcher triggers, or follow-up delivery. The queue is read-only and normalizes work-plan, research-run, connected task, approval, automation, schedule, reminder, routine-promotion, delegated-agent, and delivery cards. Research runs, connected-host tasks, approvals, automation runs, and schedules include live records with status/progress, source ids, next steps, log tails when available, task retry/output/correlation diagnostics, bounded redacted host task output route/preview descriptors, automation telemetry/delivery/route diagnostics, available controls, unavailable controls with reasons, and exact inspect/checkpoint/pause/resume/cancel/approve/deny/retry/run/edit/enable/disable/delete routes where supported. Schedule records expose pause/resume aliases over daemon enable/disable lifecycle routes so users do not have to translate scheduler terminology. Connected-host task cancel/retry uses `agent_operator_method` exact daemon methods with `confirm:true` plus `explicitUserRequest`; slash `/tasks` remains inspection-only. Inspect one card with `autonomy action:"item"`; lower-level `agent_harness mode:"autonomy_intake|autonomy_queue|autonomy_queue_item"` remains available for detailed route inspection. Create, edit, run, pause, resume, cancel, approve, deny, send, schedule, and schedule lifecycle effects stay on the owning confirmed route returned by that card.
+Use `autonomy action:"intake"` first when the user asks for ongoing work and the safest route is not obvious. It is read-only and returns the likely route, missing fields, confirmation boundary, and trigger workflow posture for time-based wakeups/schedules, incoming webhooks/watchers, Gmail/email connector triggers, and control-plane event streams. Webhook, watcher, Gmail, or event-trigger requests now point to the published `watchers.create` contract when applicable, but watcher creation is an admin connected-host mutation: require trusted source/scope, task or run target, success criteria, `confirm:true`, and `explicitUserRequest`. The intake action also returns watcher receipt success criteria plus a read-only watcher evidence contract for SDK/daemon-owned durable run-history receipts, provider source records, redacted event payload descriptors, and autonomy queue correlation. Confirmed `agent_operator_method` calls summarize `watchers.create/patch/run/start/stop/delete` receipts into certified or follow-up outcomes without exposing operator tokens. Use `schedule action:"create"` for one visible autonomous schedule, `schedule action:"remind"` for reminders, `schedule action:"edit"` for one exact schedule edit, and `schedule action:"run|pause|resume|delete"` for lifecycle controls; it forwards to the same preview, read-only current-state diff, confirmation, and connected-host routes as `agent_autonomy_schedule`, `agent_reminder_schedule`, `agent_schedule_edit`, and allowlisted `agent_operator_action`, then returns post-action next routes for schedule list, autonomy queue inspection, run, edit, pause, resume, and delete where the schedule still exists. Unconfirmed schedule and routine-promotion previews return `confirmationRoutes` so the user or model can confirm the same intent without guessing the next command. Confirmed routine schedule promotion through the workspace or `/schedule promote-routine` returns the same post-action schedule next routes. Use `autonomy action:"queue"` before creating recurring autonomous work, reminders, routine schedules, delegated work, run controls, schedule edits, approval decisions, watcher triggers, or follow-up delivery. The queue is read-only and normalizes work-plan, research-run, connected task, approval, automation, schedule, reminder, routine-promotion, delegated-agent, and delivery cards. Research runs, connected-host tasks, approvals, automation runs, SDK/daemon watcher run/source records, and schedules include live records with status/progress, source ids, next steps, log tails when available, task retry/output/correlation diagnostics, bounded redacted host task and watcher output route/preview descriptors, automation telemetry/delivery/route diagnostics, watcher run-history/source diagnostics, available controls, unavailable controls with reasons, and exact inspect/checkpoint/pause/resume/cancel/approve/deny/retry/run/edit/enable/disable/delete routes where supported. Provider-source watcher records are read-only context with inspect/refresh controls; watcher run effects appear only when the owning SDK or daemon publishes exact confirmed routes. Schedule records expose pause/resume aliases over daemon enable/disable lifecycle routes so users do not have to translate scheduler terminology. Connected-host task cancel/retry uses `agent_operator_method` exact daemon methods with `confirm:true` plus `explicitUserRequest`; slash `/tasks` remains inspection-only. Inspect one card with `autonomy action:"item"`; lower-level `agent_harness mode:"autonomy_intake|autonomy_queue|autonomy_queue_item"` remains available for detailed route inspection. Create, edit, run, pause, resume, cancel, approve, deny, send, schedule, and schedule lifecycle effects stay on the owning confirmed route returned by that card.
 
 ## Agent Knowledge
 

package/docs/voice-and-live-tts.md

@@ -20,9 +20,9 @@ GoodVibes Agent supports spoken turns as an Agent TUI feature. Text output remai
 
 `/config tts` opens the fullscreen configuration workspace for streaming provider, voice, and spoken-turn model routing.
 
-The model can inspect the same settings through `settings action:"list|get"`, use `device action:"voice|provider"` for voice/media posture and provider inspection, open the visible TTS provider or voice picker through `device action:"open_tts_provider|open_tts_voice"` with confirmation, and change Agent-owned TTS settings with `settings action:"set"` plus explicit confirmation. Lower-level `mode:"media_posture"` is compact by default; use `includeParameters:true` or `mode:"media_provider"` for full provider readiness, generation route hints, picker routes, and media policy detail. It also returns a voice workflow map for push-to-talk input, voice memo transcription, spoken responses, and wake-word capture, with ready/attention/setup-needed/not-published states and exact setup routes. Workspace action discovery includes compact `modelRoute` hints for TTS prompts, image input, and confirmed media generation; generated image/video requests use `agent_media_generate` when the user asks for that effect. Connected-host listener or lifecycle settings remain outside Agent ownership.
+The model can inspect the same settings through `settings action:"list|get"`, use `device action:"voice|provider"` for voice/media posture and provider inspection, open the visible TTS provider or voice picker through `device action:"open_tts_provider|open_tts_voice"` with confirmation, and change Agent-owned TTS settings with `settings action:"set"` plus explicit confirmation. Lower-level `mode:"media_posture"` is compact by default; use `includeParameters:true` or `mode:"media_provider"` for full provider readiness, generation route hints, picker routes, and media policy detail. It also returns a voice workflow map for push-to-talk input, voice memo transcription, spoken responses, and wake-word capture, with ready/attention/setup-needed/not-published states, exact setup routes, and certified SDK/daemon permission-scoped live records when published. Workspace action discovery includes compact `modelRoute` hints for TTS prompts, image input, and confirmed media generation; generated image/video requests use `agent_media_generate` when the user asks for that effect. Connected-host listener or lifecycle settings remain outside Agent ownership.
 
-Wake-word and always-listening capture are intentionally reported as `not-published` until the runtime exposes a permission-scoped contract. Until then, Agent should guide users to explicit voice input and `/tts` rather than implying background microphone capture exists.
+Wake-word and always-listening capture are reported as `not-published` until the runtime exposes a certified permission-scoped contract. When the SDK/daemon publishes certified wake-word records, Agent shows the permission scope, receipt evidence, and exact inspect/control routes; otherwise Agent guides users to explicit voice input and `/tts` rather than implying background microphone capture exists.
 
 ## Playback Requirements
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pellux/goodvibes-agent",
-  "version": "1.2.0",
+  "version": "1.4.1",
   "private": false,
   "description": "GoodVibes personal operator assistant TUI with a proactive Agent product brain, isolated Agent Knowledge, local profiles, routines, skills, personas, and explicit build delegation.",
   "type": "module",