@pellux/goodvibes-agent 1.1.7 → 1.2.0

package/docs/README.md

@@ -20,21 +20,28 @@ These are the package-facing docs for the GoodVibes Agent `1.0.x` release line.
 - Package executable: `goodvibes-agent`.
 - Install/runtime: Bun `1.3.10` or newer.
 - Agent version source: exact `package.json` semver, kept in sync with `CHANGELOG.md` and `src/version.ts` during release.
-- Connected-host compatibility: public Agent routes report readiness through the `compat` and `status` CLI commands plus `connected_host_status`.
+- Connected-host compatibility: public Agent routes report readiness through the `compat` and `status` CLI commands plus `host action:"status"`.
 - Connected host: owned outside Agent; Agent reports and uses it but does not manage lifecycle.
 - Agent Knowledge: only `/api/goodvibes-agent/knowledge/*`; no default knowledge fallback.
-- Local state: memory, notes, personas, skills, routines, sessions, setup, and profiles live under the Agent home.
-- Build/fix/review work: explicit delegation to GoodVibes TUI, not normal chat behavior.
+- Local state: VIBE.md personality, project context files, memory, notes, personas, skills, routines, sessions, setup, and profiles live under the Agent home or current project.
+- Computer work: local read/edit/exec routes are allowed when the current Agent workspace and permissions are sufficient; process monitor/live tail/tool inspector supervision and local file edit/write recovery are inspectable and confirmation-gated; delegation is for isolation, parallelism, remote execution, separate worktrees, or user-requested delegated review.
 
 ## Model Access Baseline
 
 Agent-owned model tools expose Agent-controlled product surfaces plus operator/audit inspection routes:
 
-- `agent_harness` for searchable mode discovery, workspace actions, slash commands, settings, panels, UI surfaces, keybindings, tool schemas, service/daemon posture, connected-host capability/status, posture catalogs, and operator/audit release artifact inspection.
+- `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_knowledge` and `agent_knowledge_ingest` for isolated Agent Knowledge.
-- `agent_local_registry` for Agent-local memory, notes, personas, skills, bundles, and routines.
-- `agent_work_plan` for visible local work-plan state.
+- `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.
+- `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.
-- `agent_channel_send`, `agent_notify`, `agent_reminder_schedule`, and `agent_media_generate` for explicit confirmed effects.
+- `agent_documents`, `agent_review_packet_presets`, `agent_review_packet_share`, `agent_artifacts`, and `research` for versioned Agent document drafts, review comments, AI suggestion review, saved artifact attachment/insertion, reviewer-ready markdown artifact export with comment and suggestion summaries, reusable review packet preset save/list/show/refresh routes with freshness checks, confirmed reviewer packet archive-reference sharing, saved artifact browsing/export/package/archive, project-local visible research run state with log tails, `research action:"briefing"` next-action queues, `research action:"plan"` route planning with browser-runner and visual-report packet contracts, `research action:"search"` bounded public source-candidate packets with confirmed capture routes, `research action:"runner"` browser-runner readiness, research source review, reviewed-source bundles, `research action:"reports|report_artifact"` saved report inspection, sourced research report artifacts with citation coverage repair hints and optional visual report packets, and reviewed artifact-to-Knowledge promotion; lower-level `agent_research_runs`, `agent_research_sources`, and `agent_research_report` remain compatibility/detail routes.
+- `agent_channel_send`, `agent_notify`, `schedule`, `setup`, `vibe`, `personal_ops action:"read"`, `import_goodvibes_settings`, lower-level schedule compatibility tools, `agent_media_generate`, and `agent_model_compare` for explicit confirmed effects, including channel send receipt ids, connected autonomous schedules, reminders, schedule edits and lifecycle controls, setup checkpoint/token/smoke/finish actions, VIBE.md init/persona import, one bounded live Personal Ops inbox/calendar read, redacted settings import preview/apply, and blind comparison from saved text artifacts with side-by-side reviewer views, split-pane reviewer handoff diffs with section jumps and recent-handoff choices, chronological review packet timeline state including packet presets and preset freshness attention, review packet wizard progress/routes/refreshed-preset lineage/share handoff, route-decision receipt artifacts for apply/leave-unchanged evidence, packet-default form prefill for export/handoff/archive/apply/save-preset/share workflows, inline reviewer-readiness badges before export/archive/apply, task/document/benchmark-filtered saved judgment analytics/synthesis, reviewer handoff artifacts, and one-click handoff ZIP archives with matching route-decision receipt evidence.
 
 Catalog modes are compact by default. `agent_harness mode:"modes"` searches all harness modes; `mode:"mode"` inspects one mode contract. Plural catalog rows keep summaries short and expose effect class, `modelRoute`, or `modelAccess` hints where the model needs an immediate route decision. Detailed schemas, route hints, redacted log tail, release artifact data, and editor fields require `includeParameters:true` or a singular inspect mode. The slash-command and CLI catalogs mirror every registered built-in command with policy and preferred model route metadata available to the model. Keybinding and fixed-shortcut rows identify direct model routes versus direct-user-only controls. Registered tool definitions use short top-level descriptions, omit nested parameter descriptions from the default model catalog, and carry direct harness inspection routes. Mutations, external delivery, UI routing, keybinding changes, setting writes, local destructive actions, media generation, reminders, and connected-host operator actions remain confirmation-gated and refuse ambiguous lookup.

package/docs/channels-remote-and-api.md

@@ -4,7 +4,7 @@ GoodVibes Agent can be reached from terminal-first and companion surfaces, but t
 
 ## Channel Posture
 
-Channel setup is explicit. Agent can inspect channel readiness, guide pairing, and send one confirmed delivery message through configured strategies, including connected-host telephony targets, but it must not silently expose a new public surface or send messages to people without a user action.
+Channel setup is explicit. Agent can inspect channel readiness, guide pairing, inspect recent redacted delivery receipts, and send one confirmed delivery message through configured strategies, including connected-host telephony targets, but it must not silently expose a new public surface or send messages to people without a user action.
 
 Agent channel UX should show:
 
@@ -12,16 +12,19 @@ Agent channel UX should show:
 - whether account/token setup is present without printing secret values;
 - the default target, if configured;
 - delivery risk and public exposure warnings;
+- the ordered setup guide step for the next channel, including setup schema, secret-backed settings, allowlist policy, live status or doctor checks, and explicit test-send boundary;
+- channel triage across setup blockers, daemon delivery attempts, visible control-plane surface messages, route bindings, and Agent receipts;
+- recent confirmed-send receipts with webhook/link target values redacted and message previews bounded;
 - the command or workspace action needed to pair companion clients through QR-first setup;
 - the confirmed `Send channel message` action when the user explicitly wants a one-off delivery.
 
-Agent-local memory, routines, skills, and personas are not automatically broadcast to channels. External delivery is an effect and requires an exact command, an explicit routine promotion, or a user-approved connected-host request. Companion pairing uses `/pair` without printing the raw token; manual token display requires `/pair --show-token --yes`. One-off delivery uses Agent Workspace -> Channels -> Send channel message or `/channels send ... --yes`.
+VIBE.md, project context files, Agent-local memory, routines, skills, and personas are not automatically broadcast to channels. External delivery is an effect and requires an exact command, an explicit routine promotion, or a user-approved connected-host request. Companion pairing uses `/pair` without printing the raw token; manual token display requires `/pair --show-token --yes`. One-off delivery uses Agent Workspace -> Channels -> Send channel message or `/channels send ... --yes`; channel triage is visible through Agent Workspace -> Channels -> Channel triage or `/channels triage`, and recent receipts are visible through Delivery receipts or `/channels deliveries`.
 
-The model can inspect pairing posture with `agent_harness` mode `pairing_posture`, and inspect one pairing route with mode `pairing_route` using `pairingRouteId`, `target`, or `query`. Those pairing modes return endpoint binding, pairing surface id, route catalog, and token fingerprint only; raw tokens and QR payloads are never returned by the read-only posture modes. QR display, manual token display, companion connection, channel delivery, task, approval, provider/model, and attachment actions stay visible user flows.
+The model can inspect pairing and device posture with `device action:"status"`, and inspect one pairing route with `device action:"capability"` using `capabilityId`, `pairingRouteId`, `target`, or `query`. Lower-level `agent_harness` modes `pairing_posture` and `pairing_route` remain available for detailed compatibility. Those routes return endpoint binding, pairing surface id, route catalog, token fingerprint, and companion device capability posture only; raw tokens and QR payloads are never returned by the read-only posture modes. QR display, manual token display, companion connection, channel delivery, task, approval, provider/model, and attachment actions stay visible user flows.
 
-The model can inspect channel-facing workspace actions with `agent_harness`, list the structured channel readiness map with `agent_harness` mode `channels`, and inspect one channel with mode `channel` using `channelId`, `target`, or `query`. Channel discovery is compact by default, and `workspace_actions` rows include `modelRoute` hints for send/setup actions. Use `includeParameters:true` or single-channel inspection when the model needs delivery target shape, read-only connected-route hints, or full route metadata. These modes are read-only: they return setup state, delivery posture, risk labels, safe config-key names, and default-target key names without printing secret values or sending messages. The model can send one explicit configured delivery through `agent_channel_send` only when the user asks for that exact effect. It must not create routes, authorize accounts, infer recipients, or expose new public surfaces from chat.
+The model can inspect channel-facing workspace actions with `workspace action:"actions|action"`, but the preferred channel route is `channels action:"status|channel|setup|triage|deliveries"`. It lists the structured channel readiness map, inspects one channel, inspects channel triage, inspects recent redacted delivery receipts, and shows the ordered channel setup guide using `channelId`, `target`, or `query`. Channel discovery is compact by default, and workspace action rows include `modelRoute` hints for send/setup actions. Use `includeParameters:true`, single-channel inspection, triage, the receipt ledger, or the setup guide when the model needs delivery target shape, read-only connected-route hints, current setup step, allowlist review route, live-check route, recent confirmed-send outcome ids, route-binding continuity, surface messages, or delivery retry candidates. These actions are read-only: they return setup state, delivery posture, risk labels, safe config-key names, default-target key names, route ids, redacted/digested external ids, and redacted receipt summaries without printing secret values or sending messages. `channels action:"triage"` reads `/api/deliveries`, `/api/control-plane/messages`, and `/api/routes/bindings` when the connected host is authenticated; it does not claim provider-specific unread Slack, Discord, or email inbox polling because the current channel contract does not publish a general inbox feed. The model can send one explicit configured delivery through `agent_channel_send` only when the user asks for that exact effect. Lower-level `agent_harness` channel modes remain compatibility/detail routes. `agent_review_packet_share` is the specialized confirmed route for sending a reviewer packet archive reference through a configured channel target without attaching ZIP bytes. It must not create routes, authorize accounts, infer recipients, or expose new public surfaces from chat.
 
-The model can inspect configured notification target posture with `agent_harness` mode `notifications`, and inspect one redacted target with mode `notification_target` using `notificationTargetId`, `target`, or `query`. Notification discovery is compact by default, while `workspace_actions` distinguishes direct `agent_notify` sends/tests from confirmed workspace routes for add/remove/clear management. Use `includeParameters:true` or single-target inspection when management route hints are needed. These modes return target count, validity, protocol/host posture, and fingerprints, but not full webhook URLs. Use `agent_notify` for one explicit confirmed notification. Use confirmed `/notify` mirrors for target management only when the user supplies the exact add/remove/clear/test intent.
+The model can inspect configured notification target posture with `agent_harness` mode `notifications`, and inspect one redacted target with mode `notification_target` using `notificationTargetId`, `target`, or `query`. Notification discovery is compact by default, while `workspace action:"actions"` distinguishes direct `agent_notify` sends/tests from confirmed workspace routes for add/remove/clear management. Use `includeParameters:true` or single-target inspection when management route hints are needed. These modes return target count, validity, protocol/host posture, and fingerprints, but not full webhook URLs. Use `agent_notify` for one explicit confirmed notification. Use confirmed `/notify` mirrors for target management only when the user supplies the exact add/remove/clear/test intent.
 
 ## Companion And Session Routes
 

package/docs/connected-host.md

@@ -1,6 +1,6 @@
 # Connected Host
 
-GoodVibes Agent is a TUI client for a connected GoodVibes host owned outside this package. The package exposes one executable:
+GoodVibes Agent is the autonomous TUI harness for a connected GoodVibes daemon. The package exposes one executable:
 
 ```sh
 goodvibes-agent
@@ -13,9 +13,9 @@ The installed command is backed by TypeScript-authored source with a Bun shebang
 - `goodvibes-agent status --json`
 - `goodvibes-agent` launches the TUI in a real PTY
 
-## Host Prerequisite
+## Daemon Prerequisite
 
-Start the owning GoodVibes host before launching Agent. Agent expects that host to expose public operator routes and the isolated Agent Knowledge routes:
+Connect to a GoodVibes daemon before using daemon-backed features. Agent expects that daemon to expose public operator routes and the isolated Agent Knowledge routes:
 
 ```text
 http://127.0.0.1:3421
@@ -51,7 +51,7 @@ For a persistent shell/session override, set:
 export GOODVIBES_AGENT_RUNTIME_URL=http://127.0.0.1:3421
 ```
 
-`GOODVIBES_AGENT_BASE_URL` is accepted as a legacy alias. These values only select the connected GoodVibes API root; they do not make Agent own host processes.
+`GOODVIBES_AGENT_BASE_URL` is accepted as a legacy alias. These values select the connected GoodVibes API root.
 
 If the connected host is unavailable, unauthenticated, or incompatible with Agent, the Agent TUI reports actionable diagnostics without printing token values.
 
@@ -65,20 +65,22 @@ Use the TUI first for those checks:
 
 ## Product Boundary
 
-Agent owns the operator assistant TUI, local profiles, local memory/notes/routines/skills/personas, isolated Agent Knowledge calls, companion chat, approvals/automation visibility, and explicit build delegation.
+Agent owns the user-facing autonomous harness: terminal renderer, setup, chat, profiles, VIBE.md personality, project context files, local memory/notes/routines/skills/personas, isolated Agent Knowledge calls, companion chat, visible agents, approvals, schedules, automation posture, daemon method access, channel delivery, reminders, and media workflows.
 
-Agent does not own connected-host lifecycle. It does not provide commands to install, expose, start, stop, restart, or mutate the connected GoodVibes host.
+The GoodVibes daemon owns the platform capabilities. Agent should expose those capabilities through the easiest safe user path: simple first-class tools for common tasks, dynamic operator method discovery for exact contract parity, and confirmation gates for write/admin routes.
 
-The model can inspect this boundary with `agent_harness` mode `connected_host`. `daemon` is an alias for the same posture report. By default the report is compact: configured base URL, token posture, ownership, mode hints, capability counts, and a short `modelRoute` for the next safe Agent-owned route. Use `includeParameters:true` for full route families, allowed capabilities, blocked capabilities, and first-class Agent tool availability; those expanded rows also carry compact `modelRoute` hints. Allowed capabilities include read-only operator briefing, explicit allowlisted approval/automation/schedule actions, isolated Agent Knowledge read/ingest, confirmed channel or notification delivery, confirmed reminder schedules, and configured media generation. Blocked capabilities include connected-host lifecycle, listener mutation, default or non-Agent knowledge fallback, hidden background Agent jobs, implicit delegated review, route/account creation, and arbitrary connected-host mutations. To inspect one surface without parsing the full report, use `connected_host_capability` with `capabilityId`, `target`, or `query`; capability results return the allowed or blocked route hint.
+The model can inspect this boundary with `host action:"capabilities"`. By default the report is compact: configured base URL, token posture, ownership, mode hints, capability counts, and a short `modelRoute` for the next safe Agent-owned route. Use `includeParameters:true` for full route families, allowed capabilities, blocked capabilities, and first-class Agent tool availability; those expanded rows also carry compact `modelRoute` hints. Allowed capabilities include read-only operator briefing, explicit allowlisted approval/automation/schedule actions, isolated Agent Knowledge read/ingest, confirmed channel or notification delivery, confirmed reminder schedules, and configured media generation. Blocked capabilities include connected-host lifecycle, listener mutation, default or non-Agent knowledge fallback, hidden background Agent jobs, implicit delegated review, route/account creation, and arbitrary connected-host mutations. To inspect one surface without parsing the full report, use `host action:"capability"` with `capabilityId`, `target`, or `query`; capability results return the allowed or blocked route hint. Lower-level `agent_harness` modes `connected_host`, `connected_host_capability`, and `daemon` remain compatibility routes.
 
-The model can inspect the public operator method catalog with `agent_harness` mode `operator_methods`. That report lists the allowlisted read and mutation methods, their public routes, owning first-class model tools, confirmation policy, and boundary. To inspect one method without parsing the full report, use `operator_method` with `methodId`, `target`, or `query`. This is a read-only catalog and does not expose arbitrary route invocation.
+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 `agent_harness` mode `service_posture`. That report exposes the same read-only endpoint binding, network-facing posture, issue, 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 `service_endpoint` with `endpointId`, `target`, or `query`; valid endpoint ids are `controlPlane`, `httpListener`, and `web`. These modes are diagnostic only and do not expose host start, stop, restart, install, listener, or account-management operations.
+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 live connected-host readiness with `agent_harness` mode `connected_host_status`. `daemon_status` is an alias. That report uses the same read-only status probe as the CLI: it checks the connected-host status route, verifies host compatibility, checks the isolated Agent Knowledge status route 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. It is diagnostic only and does not expose host start, stop, restart, install, listener, or account-management operations.
+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 companion pairing posture with `agent_harness` mode `pairing_posture`, and inspect one pairing/mobile route with `pairing_route`. Those modes report the control-plane endpoint binding, pairing surface id, token presence/fingerprint, and route catalog 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 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.
 
 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.
 
-Normal assistant chat uses companion chat. Build/fix/review work is delegated explicitly to GoodVibes TUI through public runtime/session contracts, and delegated review is requested only when explicitly asked for build/fix/review work.
+Normal assistant chat can use local tools, visible Agent jobs, daemon automation, shared sessions, delegation, or remote runners. GoodVibes TUI remains the vibecoding harness; Agent should choose it when that UX is best for the user rather than exposing package ownership as friction.

package/docs/getting-started.md

@@ -1,14 +1,12 @@
 # Getting Started
 
-GoodVibes Agent is the installable `1.0.x` personal operator assistant TUI for GoodVibes.
+GoodVibes Agent is the installable autonomous operator assistant for GoodVibes.
 
 ## Requirements
 
 - Bun `1.3.10` or newer.
-- A connected GoodVibes host with compatible public Agent routes.
-- Connected-host token/config state accepted by that host.
-
-Agent does not launch or manage the connected host.
+- A connected GoodVibes daemon or compatible host with operator routes.
+- Token/config state accepted by that daemon.
 
 ## Install From Package
 
@@ -42,13 +40,17 @@ Use the interactive workspace first. CLI subcommands are secondary support paths
 
 Primary first-run areas:
 
-- Setup: provider/model, connected-host compatibility, Agent Knowledge readiness, profiles, support bundles, subscriptions, and auth review.
-- Home: normal chat, operator briefing, model selection, and health.
+- 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.
+- 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.
-- Memory & Skills: local memory, notes, personas, skills, routines, and learned behavior capture.
-- Channels: companion pairing, channel readiness, notification targets, and confirmed sends.
-- Voice & Media: TTS setup, image input, and confirmed generated media.
+- 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.
+- 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.
+- 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.
 - 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.
 
 Press `/` inside the Agent workspace to search actions by name, category, command, or detail.
 
@@ -67,20 +69,31 @@ 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 |
 | Harness mode discovery | `agent_harness mode:"modes"`, `mode:"mode"` |
-| Workspace actions | `agent_harness mode:"workspace_actions"`, `mode:"workspace_action"`, `mode:"run_workspace_action"` |
-| Slash commands | `agent_harness mode:"commands"`, `mode:"command"`, `mode:"run_command"` |
-| Settings | `agent_harness mode:"settings"`, `mode:"get_setting"`, `mode:"set_setting"`, `mode:"reset_setting"` |
-| Visible UI | `agent_harness mode:"panels"`, `mode:"ui_surfaces"`, `mode:"open_panel"`, `mode:"open_ui_surface"` |
-| Keybindings | `agent_harness mode:"shortcuts"`, `mode:"keybindings"`, `mode:"keybinding"`, `mode:"run_keybinding"`, `mode:"set_keybinding"` |
+| 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 |
+| 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` |
-| Local memory/notes/personas/skills/routines | `agent_local_registry` or confirmed workspace actions |
-| Work plan | `agent_work_plan` |
-| Channels, notifications, reminders, media | `agent_channel_send`, `agent_notify`, `agent_reminder_schedule`, `agent_media_generate` |
-| Operator state/actions | `agent_operator_briefing`, `agent_operator_action`, `agent_harness mode:"operator_methods"` |
-| Connected host/daemon posture | `agent_harness mode:"service_posture"`, `mode:"connected_host"`, `mode:"connected_host_capability"`, `mode:"connected_host_status"`, `mode:"daemon"`, `mode:"daemon_status"` |
-| Operator/audit evidence | `agent_harness mode:"release_evidence"`, `mode:"release_evidence_artifact"`, `mode:"release_readiness"`, `mode:"release_readiness_item"` |
+| 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 |
+| 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 |
+| Learning curator and prompt plan | `memory action:"curator" includeParameters:true`, `memory action:"candidate"`, `agent_learning_consolidation`; lower-level learning harness modes remain available for detail |
+| Work plan | `agent_work_plan` including confirmed `dispatch_agents` for approved visible-agent work |
+| Visible autonomous work | `agent_harness mode:"agent_orchestration"`, `mode:"agent_orchestration_agent"`, then `agent` with `mode:"spawn"`, `mode:"batch-spawn"`, `mode:"status"`, `mode:"message"`, `mode:"wait"`, or `mode:"cancel"` |
+| Channels, notifications, reminders, scheduled autonomy, media | `channels action:"status|channel|setup|triage|deliveries"`, `agent_channel_send`, `agent_notify`, `schedule action:"list|create|remind|edit|run|pause|resume|delete"`, lower-level channel harness modes and `agent_reminder_schedule`/`agent_autonomy_schedule`/`agent_schedule_edit`, `agent_media_generate` |
+| Operator state/actions | `agent_operator_briefing`, `agent_operator_action`, `agent_operator_method`; inspect method contracts with `host action:"methods|method"` |
+| Connected host/daemon posture | `host action:"status|capabilities|capability|services|service|methods|method"`; lower-level connected-host harness modes remain available for detailed inspection |
+| First-run setup plan | `setup action:"status"` exposes `setupCloseout`; use `action:"repair"` for the safest next repair route, `action:"item"`, `action:"checkpoint"`, `action:"save_checkpoint"`, `action:"clear_checkpoint"`, `action:"token"`, `action:"smoke"`, and confirmed `action:"finish"` for the guided setup path |
+| Operator/audit evidence | `audit action:"readiness|item|evidence|artifact"`; lower-level `agent_harness mode:"release_evidence"`, `mode:"release_evidence_artifact"`, `mode:"release_readiness"`, and `mode:"release_readiness_item"` remain available |
 
 All effects require explicit user request and confirmation. Ambiguous lookup is refused with candidates.
 
@@ -101,26 +114,33 @@ goodvibes-agent profiles templates
 goodvibes-agent profiles create household --template household --yes
 goodvibes-agent profiles use household --yes
 goodvibes-agent --agent-profile household
-goodvibes-agent profiles templates export research ./research-starter.json --yes
+goodvibes-agent profiles templates export research ./research-starter.json --include-vibe --yes
 goodvibes-agent profiles templates import ./research-starter.json --yes
 ```
 
-Named profiles isolate Agent-local config, sessions, memory, notes, personas, skills, routines, and setup state. They do not start or isolate the connected host.
+Named profiles isolate Agent-local config, sessions, VIBE.md, memory, notes, personas, skills, routines, and setup state. Starter export/from-discovered flows can include the current safe VIBE.md with `--include-vibe`; blocked VIBE.md files must be repaired first. Shared GoodVibes settings import can reuse existing provider, UI, permission, subscription, surface, tool, and daemon endpoint settings from goodvibes-tui and other published GoodVibes platform stores. The direct `settings action:"import"` route, `import_goodvibes_settings` compatibility route, and workspace action all preview changed counts first, show source-package ownership metadata, redact secret values, and require confirmation before applying Agent-owned settings or provider subscriptions without mutating the source package stores.
 
 ## Local Behavior
 
-Memory, notes, personas, routines, and Agent skills are local to GoodVibes Agent. They do not write into default knowledge or other product segments.
+VIBE.md is the friendly personality file for GoodVibes Agent. Project and global VIBE.md files are discovered, scanned for secret-looking content, surfaced in the Local Context and Personas workspaces, setup, and the learning curator when blocked or truncated, optionally carried through profile starter export/import with `--include-vibe`, and applied to the serial Agent conversation. The model-visible route is `vibe action:"status|show"` for inspection and `vibe action:"init|import_persona" confirm:true explicitUserRequest:"..."` for confirmed personality changes; previews also return exact model and CLI `confirmationRoutes` for the same init/import action. They do not write into default knowledge or other product segments.
+
+Project context files are workspace instructions, not personality. GoodVibes Agent discovers `.hermes.md`, `HERMES.md`, `AGENTS.md`, `CLAUDE.md`, optional `HERMES_HOME/SOUL.md`, `.cursorrules`, and `.cursor/rules/*.mdc`, scans them for secret-looking content, applies bounded safe content to the serial Agent prompt, shows loaded/blocked/truncated counts in Local Context, and exposes loaded or blocked files through `context action:"files"` and `context action:"file"`. Subdirectory context is discovered when a target path is supplied.
+
+Memory, notes, personas, routines, and Agent skills are local to GoodVibes Agent. Only reviewed, high-confidence local context should steer the assistant. Prompt context includes reviewed memory at or above the durable confidence threshold and reviewed setup-ready skills, routines, bundles, and personas. Enabled but unreviewed, stale, low-confidence, setup-blocked, or blocked context records are surfaced as suppressed review work instead of being applied silently. 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 a compact receipt timeline with outcome counts, latest turn outcome, applied/suppressed counts, bounded outcome detail, exact latest-receipt drill-in, and outcome filter routes. Use `context action:"prompt"`, `context action:"receipts"`, or `context action:"receipt"` when the model or operator needs the current applied order, recent receipt ids, exact `receiptId`, `turnId`, or `outcomeStatus` filtering, turn outcomes, selected records, suppressed records, prompt previews on request, and approximate token budget.
 
 Use the workspace first:
 
 - Memory & Skills -> Create memory, Create note, or Capture learned behavior.
+- Memory & Skills -> Prompt plan to see which reviewed memories and setup-ready behaviors can guide the assistant now, what is suppressed, and which scored review/proposal/consolidation routes should run before context expands.
+- Memory & Skills -> Learning curator to rank stale, low-confidence, missing-setup, VIBE.md personality health, duplicate-consolidation candidates with visible diffs and rollback/recreate routes, expose an ordered duplicate-consolidation batch review plan, apply confirmed merge/stale/delete/rollback/recreate phases through `agent_learning_consolidation`, surface reviewed-note memory/behavior proposals, completed-work memory/behavior proposals, completed-research memory/behavior proposals, saved-session memory/behavior proposals, and review-needed local behavior records before they silently guide the assistant.
+- Local Context -> Prompt context, Inspect VIBE.md, Inspect project context, or Inspect one context file before relying on persistent personality or project instructions.
 - Notes -> Create notes for source triage, temporary decisions, and operator handoff.
-- Personas -> Create, inspect, activate, review, stale, or delete.
+- Personas -> Inspect, create, show, or import VIBE.md; create, inspect, activate, review, stale, or delete personas.
 - Skills -> Create, enable/disable, review, bundle, or delete.
 - Routines -> Create, start in chat, review receipts, or explicitly promote to a connected schedule.
 - Work -> Add work item, review work plan, and update status.
 
-Starting a routine records local usage and prints its steps in the main conversation. It does not start background automation. Promotion to a connected schedule is separate, explicit, confirmation-gated, and keeps Agent Knowledge isolated.
+Starting a routine records local usage and prints its steps in the main conversation. Promotion to a connected schedule or automation job is separate, explicit, confirmation-gated, visible in the autonomy queue, and keeps Agent Knowledge isolated. When the user asks for recurring autonomous work directly, use `schedule action:"create"` to create one connected schedule only with explicit task, cadence, success criteria, confirmation, and user request provenance; use `schedule action:"remind"` for reminders and `schedule action:"pause|resume|run|delete"` for exact-id lifecycle controls. Confirmed schedule creation, routine promotion, reminders, edits, and lifecycle actions return next routes for schedule list, autonomy queue inspection, run, edit, pause, resume, and delete when applicable.
 
 ## Knowledge And Artifacts
 
@@ -134,13 +154,13 @@ 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 and URL inspection. Research requests do not ingest sources. 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, 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 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.
 
 ## Connected Host
 
-Start the owning GoodVibes host before using connected features. Agent expects:
+Connect Agent to a GoodVibes daemon before using daemon-backed features. Agent expects:
 
 ```text
 http://127.0.0.1:3421
@@ -167,8 +187,14 @@ Host diagnostics:
 - `goodvibes-agent doctor`
 - `goodvibes-agent compat`
 
-Model-visible diagnostics are `service_posture`, `service_endpoint`, `connected_host`, `connected_host_status`, `connected_host_capability`, `daemon`, and `daemon_status`. Connected-host posture/status/capability results include compact route hints for the next safe Agent-owned tool or harness mode. These modes are read-only and do not expose host lifecycle control.
+Model-visible diagnostics prefer `host action:"status|capabilities|capability|services|service|methods|method"`. Lower-level `service_posture`, `service_endpoint`, `connected_host`, `connected_host_status`, `connected_host_capability`, `daemon`, and `daemon_status` harness modes remain available for compatibility and detailed inspection. `agent_operator_method` can run read-only routes directly and write/admin routes only with `confirm:true` plus `explicitUserRequest`.
+
+When no connected host is reachable, inspect `setup action:"item" setupItemId:"connected-host-readiness"` for the offline bootstrap plan. It returns user-run commands to verify Bun, install and trust the owning GoodVibes host package, verify host entrypoints, start the GoodVibes service, and reconnect Agent. Agent does not run those host install/start commands implicitly. When the host auth token is missing or malformed on the local machine, use `setup action:"token" setupItemId:"connected-host-auth" confirm:true explicitUserRequest:"..."`; it uses the GoodVibes SDK pairing helper to create or repair `~/.goodvibes/daemon/operator-tokens.json`, preserves valid existing tokens, leaves environment tokens untouched, and returns only path/fingerprint metadata.
 
 ## Current Product Notes
 
-Agent uses the GoodVibes terminal shell, renderer, input, fullscreen workspace, command registry, and release foundation. The active policy is serial/proactive by default, blocks hidden Agent-owned job fanout, and delegates explicit build/fix/review work to GoodVibes TUI instead of turning Agent into a coding TUI.
+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.
+
+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.
+
+Security policy decisions are inspectable before execution. The route planner sends active permission or approval questions to `security action:"status"`, incident/finding/leaked-secret questions to `security action:"finding"`, and blocked-action or confirmation questions to `security action:"explain"` before any risky work is attempted. Use `security action:"explain" toolName:"<tool>" toolArgs:{...}` or lower-level `agent_harness mode:"policy_explain"` to see the Agent route guard, permission-mode prediction, typed-confirmation requirement, redacted argument preview, and exact follow-up routes for one model action. The explanation is read-only; final execution still uses the live safety guard, permission prompt, and owning tool confirmation.

package/docs/knowledge-artifacts-and-multimodal.md

@@ -8,11 +8,11 @@ GoodVibes Agent uses these context layers:
 
 - current conversation context for the active turn;
 - Agent-local memory records for durable but private assistant facts and preferences;
-- Agent-local routines, skills, and personas for reusable behavior profiles;
+- VIBE.md personality files, project context files, plus Agent-local routines, skills, and personas for reusable behavior profiles;
 - isolated Agent Knowledge for source-backed documents, search, and semantic answers;
 - artifacts for uploaded/generated files that can be referenced by chat, delegation, or explicit Agent Knowledge ingestion.
 
-These layers are intentionally separate. Local memory/routines/skills/personas are not automatically promoted into Agent Knowledge. Agent Knowledge records are not copied into default knowledge. Secrets are rejected or represented only by explicit secret references.
+These layers are intentionally separate. VIBE.md, project context files, local memory/routines/skills/personas, and default knowledge are not automatically promoted into Agent Knowledge. Agent Knowledge records are not copied into default knowledge. Secrets are rejected or represented only by explicit secret references.
 
 ## Agent Knowledge Boundary
 
@@ -78,7 +78,7 @@ The main assistant conversation can use the read-only `agent_knowledge` tool for
 
 ## Ingest
 
-Use Agent Workspace -> Knowledge for URL, URL-list, file, bookmark, browser-history, connector ingest, issue review, consolidation, and reindex forms. The main assistant conversation can also call the confirmed `agent_knowledge_ingest` tool for URL, file, URL-list, bookmark, browser-history, and connector source families. `/knowledge ingest-url <url> --yes` and `goodvibes-agent knowledge ingest-url <url> --yes` ingest URL sources into Agent Knowledge only.
+Use Agent Workspace -> Knowledge for URL, URL-list, file, artifact-id, bookmark, browser-history, connector ingest, issue review, consolidation, and reindex forms. The main assistant conversation can also call the confirmed `agent_knowledge_ingest` tool for URL, file, artifact-id, URL-list, bookmark, browser-history, and connector source families. `/knowledge ingest-url <url> --yes` and `goodvibes-agent knowledge ingest-url <url> --yes` ingest URL sources into Agent Knowledge only.
 
 The TUI workspace exposes the common confirmed ingest, issue-review, consolidation, and reindex flows. The CLI also exposes Agent-specific batch routes for scripts:
 
@@ -91,15 +91,17 @@ The TUI workspace exposes the common confirmed ingest, issue-review, consolidati
 
 Connected-host ingest and read CLI routes target `/api/goodvibes-agent/knowledge/*`. Workspace and slash-command issue review, packet/explain, consolidation, and reindex flows stay inside the isolated Agent Knowledge service. None of them call default knowledge.
 
-Do not map local memory, notes, routines, skills, personas, or default knowledge documents into Agent Knowledge automatically. Durable source-backed facts can be ingested deliberately through Agent routes when the user or an explicit Agent workflow asks for it.
+Do not map VIBE.md, project context files, local memory, notes, routines, skills, personas, or default knowledge documents into Agent Knowledge automatically. Durable source-backed facts can be ingested deliberately through Agent routes when the user or an explicit Agent workflow asks for it.
 
 ## Artifacts And Multimodal
 
 Artifacts are first-class runtime objects for files, images, audio, video, generated outputs, and delegation results. Agent Knowledge use of artifacts must still go through Agent-specific ingest routes when those are available.
 
+The saved artifact browser is available from Agent Workspace -> Artifacts -> Browse artifacts and through `agent_artifacts`. It lists recent uploads, exports, generated media, source artifacts, session artifacts, comparison artifacts, sourced research reports, and exported document drafts with filters for query, kind, MIME type, purpose, and source. `agent_artifacts mode:"show"` inspects one artifact by id with redacted metadata and a bounded preview for text-like content only; binary bytes and inline base64 stay out of the transcript. Agent Workspace -> Artifacts -> Export saved artifact copies one reviewed artifact to a workspace file after typed confirmation, preserves exact bytes for text or binary artifacts, and refuses overwrite unless explicitly enabled. Agent Workspace -> Artifacts -> Export package copies selected reviewed artifact ids into a workspace package directory or ZIP archive with exact bytes under `artifacts/`, a redacted `manifest.json`, and a README. Agent Workspace -> Artifacts -> Attach to document draft links one reviewed saved artifact id to a document without rewriting the body, while Promote to Knowledge and Documents & Compare -> Promote artifact to Knowledge ingest one reviewed saved artifact id through the isolated Agent Knowledge artifact route after typed confirmation.
+
 Agent Workspace -> Voice & Media -> Generate media creates image/video artifacts through configured media providers after typed confirmation. The main conversation can perform the same confirmed action with the `agent_media_generate` tool when the user explicitly asks for generated media. Generated media output is summarized as artifact ids, MIME types, filenames, and source URLs when present; inline base64 is not printed into the transcript.
 
-The model can use first-class tools for the common Knowledge and media workflows: `agent_knowledge`, `agent_knowledge_ingest`, and `agent_media_generate`. `agent_harness` adds workspace-action lookup/execution, compact `modelRoute` hints in `workspace_actions`, `media_posture`/`media_provider` readiness, `sessions`/`session` bookmark and artifact posture, and confirmed slash-command mirrors when a visible workspace route maps to a concrete command.
+The model can use first-class tools for the common route-selection, Knowledge, document, packet preset, packet share, artifact, autonomy, research, model/provider, computer/browser, device/voice, security, media, and comparison workflows: `route`, `agent_knowledge`, `agent_knowledge_ingest`, `agent_documents`, `agent_review_packet_presets`, `agent_review_packet_share`, `agent_artifacts`, `autonomy`, `research`, `models`, `computer`, `device`, `security`, `agent_media_generate`, and `agent_model_compare`. `route action:"plan"` maps a plain user request to the preferred visible Agent route, alternatives, missing fields, confirmation boundary, workspace matches, and harness mode matches without executing tools. `agent_documents` creates, revises, reviews, comments on, suggests changes to, lists, shows, attaches saved artifacts to, inserts saved artifacts into, and exports project-scoped versioned markdown drafts as saved artifacts after explicit confirmation for writes. Exports include a reviewer appendix with comment and AI suggestion summaries plus metadata counts for open/resolved comments and proposed/accepted/rejected suggestions. Suggested changes stay pending until the user accepts or rejects them; acceptance appends a new draft version. Artifact attachment records a reusable artifact reference and export manifest without changing the document body; text artifact insertion adds bounded markdown content to a new draft version; non-text artifact insertion adds a safe reference block without binary bytes or base64. `agent_review_packet_presets mode:"save"` writes one confirmed local JSON artifact containing reusable document/export/comparison/judgment/route-decision/handoff/archive/related artifact ids; `mode:"list"` and `mode:"show"` inspect saved presets, flag missing or superseded saved ids, and recommend newer matching reuse routes when metadata is sufficient; `mode:"refresh"` saves one new confirmed preset artifact from those freshness recommendations while preserving the source preset and without mutating documents, model routing, handoffs, or archives. `agent_review_packet_share` validates one saved reviewer handoff archive and sends a confirmed plain-text archive reference through a configured channel target without printing or attaching ZIP bytes; exact bytes still move through explicit artifact export/package routes. `research action:"briefing|plan|search|runner|runs|run|sources|source|bundle|reports|report_artifact"` exposes a read-only next-action queue, read-only planning, bounded public source-candidate search, browser-runner readiness, run/source inspection, reviewed-source bundles, and saved research report artifact inspection; confirmed `research action:"create_run|start_run|checkpoint|pause|resume|cancel|complete|fail|delete_run|add_source|review_source|reject_source|use_source|delete_source|report"` performs one visible research mutation or sourced report save after explicit user request. `models action:"status|route|local|providers|provider"` exposes read-only model route, local cookbook, provider, and subscription posture; confirmed `models action:"smoke"` performs local server smoke checks through existing confirmation gates. `computer action:"status|plan|control|browser|setup|mcp"` exposes read-only browser/PWA, browser/screenshot/desktop-control planning, repair/setup, and trusted tool discovery posture; confirmed `computer action:"open_browser"` performs the visible browser cockpit handoff through existing confirmation gates. `device action:"status|capability|voice|provider"` exposes read-only companion/mobile, voice, and provider posture; confirmed `device action:"open_tts_provider|open_tts_voice"` performs visible TTS picker handoffs through existing confirmation gates. `security action:"status|finding|explain"` exposes redacted security posture, exact finding inspection, and read-only policy explanations for why one model action is allowed, denied, or waiting on confirmation. The lower-level `agent_research_runs`, `agent_research_sources`, `agent_research_report`, `agent_harness mode:"route_decision"`, `agent_harness mode:"research_briefing"`, provider/model, pairing/media posture, security posture, policy explanation, and UI-surface harness modes remain available as detailed compatibility routes over the same local records, artifacts, and route contracts. `research action:"briefing"` summarizes local run/source/report/browser posture and returns exact follow-up routes without writes. Research run state keeps plan, phase, progress, checkpoints, log tails, source ids, lifecycle controls, and no hidden background execution. `research action:"search"` runs bounded public web research and returns source candidates with exact confirmed `add_source` routes; it never writes the source queue by itself. Research sources keep credibility, score, report-ready source lines, reviewed-source bundle handoff, and review/reject/use state; they never ingest Agent Knowledge or save a report by themselves. Research reports save one confirmed sourced markdown artifact with a source map, redacted source URLs, source-count metadata, citation coverage metadata, repair hints, optional strict body-citation enforcement, optional `visualReport:true` packet sections, direct `research action:"reports|report_artifact"` inspection, and no inline report content in the transcript. `agent_artifacts mode:"export"` copies exact saved artifact bytes to a validated workspace path after confirmation and refuses accidental overwrite; `mode:"package"` copies selected saved artifacts into a validated workspace directory with exact bytes, redacted metadata, README, and manifest; `mode:"archive"` writes the same package payload as one ZIP file. `agent_knowledge_ingest` accepts `sourceKind:"artifact"` plus `artifactId` for reviewed saved-artifact promotion. Blind model comparison can run from a direct prompt or a saved text artifact id, saves a local JSON artifact with the full prompt, blinded outputs, source artifact metadata, and reveal map while keeping model identities hidden in the transcript until reveal; saved artifacts can be reopened as blind review boards from Documents & Compare, rendered as side-by-side reviewer views with related document/artifact excerpts, converted into confirmed judgment artifacts, summarized as task/document/benchmark-filtered saved preference analytics or synthesized into cross-session preference themes, exported as local markdown reports, combined with related document or artifact exports into reviewer handoff artifacts, compared through split-pane reviewer handoff diffs with section jumps and recent-handoff choices from artifact metadata, archived as one ZIP artifact with the handoff, source comparison or judgment, related evidence bytes, matching route-decision receipt bytes, README, archive metadata, and redacted manifest, applied to the main model route only through a separate confirmed winner-update action, and saved as apply-winner or leave-unchanged route-decision receipt artifacts. Documents & Compare shows a chronological review packet timeline across document, comment, suggestion, attachment, export, compare, judgment, route-decision receipt, packet preset, handoff, and archive events plus a read-only review packet wizard for progress, current route hints, backtracking, route-decision guidance, refreshed-preset lineage, final archive review, and the confirmed share route. Workspace forms show inline reviewer-readiness badges before document export, reviewer handoff/archive, and route-apply actions, and packet-default hints prefill export, handoff/archive, apply, leave-unchanged, save-preset, and share fields from the latest review packet, falling back to saved preset metadata only when live evidence is missing, without bypassing confirmation. `autonomy` adds ongoing-work route selection plus visible queue and item inspection; lower-level `agent_harness` adds workspace-action lookup/execution, compact `modelRoute` hints in `workspace_actions`, compatibility autonomy modes, live research run, connected-host task, approval, automation run, and schedule records/log tails, lower-level research/device/media mode inspection, `document_ops`/`document_ops_lane` readiness including review packet timeline with stale preset attention, guided packet wizard progress, refreshed-preset lineage, route-decision receipts, packet presets/defaults/share handoff and freshness posture, and visible reviewer-readiness preflight for unresolved comments/suggestions/source evidence/comparison reveal/route decisions/handoff evidence, `sessions`/`session` bookmark and artifact posture, and confirmed slash-command mirrors when a visible workspace route maps to a concrete command.
 
 Multimodal outputs should stay in the conversation, artifacts, local notes or memory, or explicit delegation results unless the user explicitly ingests a reviewed source through an Agent Knowledge route. They must not be inserted into default knowledge.
 

package/docs/project-planning.md

@@ -68,9 +68,9 @@ Use natural language such as "pause planning" or "stop planning" when planning s
 
 The work-plan tracker is for concrete, durable task state after work becomes actionable. It is separate from the planning interview loop.
 
-Use `/workplan` when the work already has tasks and needs status tracking. Use `/delegate` when explicit build/fix/review work should go to GoodVibes TUI.
+Use `/workplan` when the work already has tasks and needs status tracking. Use `/delegate` when explicit build/fix/review work should go to GoodVibes TUI; include the original ask, delegation reason, success evidence, workspace/worktree hint, priority, and explicit review intent.
 
-The model can keep the same visible work plan current with `agent_work_plan`. It can also inspect planning/work-plan visibility through `agent_harness` workspace and panel metadata, and inspect explicit build-delegation posture with `delegation_posture`/`delegation_route`; destructive work-plan changes and delegated submissions still require explicit user request and confirmation.
+The model can keep the same visible work plan current with `agent_work_plan`. Approved items can be dispatched through confirmed `agent_work_plan action:"dispatch_agents"` into visible `agent` spawn or batch-spawn calls, with linked-agent receipts written back to the plan and post-dispatch next routes for orchestration, work-plan detail, agent inspect/wait/message/cancel, and closeout. Those linked receipts and matching remote-runner artifacts appear in `agent_harness mode:"agent_orchestration"` closeout cards with exact work-plan and artifact review routes. It can also inspect planning/work-plan visibility through `agent_harness` workspace and panel metadata, and inspect explicit build-delegation posture with `delegation action:"status|routes|route"`; destructive work-plan changes, agent dispatch, and delegated submissions still require explicit user request and confirmation.
 
 ## Agent Knowledge Boundary
 

package/docs/providers-and-routing.md

@@ -11,8 +11,8 @@ Provider and model state should be visible in:
 - `/model` and `/provider`;
 - the Agent operator workspace setup checklist;
 - the TTS configuration workspace when spoken turns are used.
-- `agent_harness` modes `model_routing` and `model_route` when the model needs read-only provider/model route posture, selectable model metadata, pinned model status, reasoning support, context-window posture, and safe setting keys. `model_routing` is compact by default; use `includeParameters:true` or `model_route` for full capabilities and route-change hints. Workspace model actions also expose compact `modelRoute` hints for settings, pin/unpin, reasoning effort, and visible picker flows.
-- `agent_harness` modes `provider_accounts` and `provider_account` when the model needs read-only provider auth route posture, subscription freshness, usage windows, route issues, and repair guidance without tokens or authorization codes. `provider_accounts` is compact by default; use `includeParameters:true` or `provider_account` for route records, usage windows, issues, notes, and auth-flow hints. Provider/account mutations stay on confirmed workspace or settings routes.
+- `models action:"status|route|local|providers|provider|smoke"` when the model needs provider/model route posture, selectable model metadata, pinned model status, reasoning support, context-window posture, readiness scores, safe setting keys, provider auth posture, subscription freshness, or the hardware-scored local model cookbook. Use `includeParameters:true`, `action:"route"`, or `action:"provider"` for full capabilities, readiness dimensions, local hardware profile, fit scores, setup/download guidance, local endpoint candidates with exact endpoint inspection, model-list smoke commands, success criteria, failure triage, confirmed local model-list smoke results, confirmed benchmark action routes, saved benchmark evidence, route-change hints, usage windows, issues, notes, and auth-flow hints.
+- Lower-level `agent_harness` modes `model_routing`, `model_route`, `provider_accounts`, `provider_account`, and confirmed `run_local_model_smoke` remain available for compatibility and detailed harness inspection. Provider/account mutations stay on confirmed workspace or settings routes.
 
 When a selected model is provider-qualified, Agent keeps the runtime provider row and raw model id separate. For example, `openai-subscriber` plus `openai:gpt-5.5` should route as provider `openai-subscriber` and model `gpt-5.5` where the public route expects provider/model fields.
 
@@ -26,6 +26,14 @@ Agent-owned provider definitions live under the Agent profile root when supporte
 
 These files are local configuration. They are not Agent Knowledge records and should not be copied into knowledge search state.
 
+## Local Model Cookbook
+
+Agent Workspace -> Model Routing exposes `Inspect route readiness`, `Local model cookbook`, `Check local servers`, `Run local benchmark`, and `Review benchmark evidence` as separate actions so users can inspect, compare, and decide without implicit route changes. `Local model cookbook` and `models action:"local"` provide recommendations for Ollama, llama.cpp, vLLM, and local OpenAI-compatible servers. The cookbook detects local-compatible provider ids and model routes when available, scans local OS CPU/RAM/platform data with safe accelerator hints, ranks recipe fit, recommends the easiest first route, and exposes setup plans with download/start guidance, local server endpoint candidates, exact `models action:"route"` endpoint inspection, model-list smoke commands, success criteria, failure triage, confirmed `models action:"smoke"` checks for detected or default local endpoints, provider-add route hints when no route exists yet, provider-refresh routes, a confirmed `Run local benchmark` model-lane action backed by `agent_model_compare`, and saved local benchmark comparison artifacts when they exist.
+
+Every selectable model and local recipe gets a 0-100 readiness score with dimensions for latency, context window, tool support, vision, cost, and privacy. Scores are estimated unless a live route benchmark has been recorded; they are intended for triage, not as hidden permission to switch the user's default model. Saved local benchmark artifacts are tagged through `agent_model_compare` with `benchmarkKind:"local-model-route"` and `taskType:"local-model-route"`; revealed winner judgments raise matching recipe confidence to measured evidence, and benchmark analytics open on that filtered slice. Default-model changes still require a separate confirmed route update.
+
+The cookbook does not probe drivers, call local network endpoints, install servers, download models, or change the selected route. Live local benchmark execution is a separate confirmed action that spends model tokens, saves comparison evidence, and leaves default-model changes to a separate revealed judgment and confirmed apply step.
+
 ## Discovery And Health
 
 Provider discovery and health are owned by the connected GoodVibes host. Agent can display discovered provider status, model context information, and route failures. It should not hide provider failures behind fallback wording that makes a failed chat or knowledge request look successful.
@@ -41,7 +49,7 @@ Search, voice, media, and multimodal providers are valid Agent features when the
 
 Outputs that should become durable knowledge must go through Agent Knowledge routes. No provider output should be inserted into default knowledge or another product segment by Agent.
 
-Setting discovery is compact by default and full with `includeParameters:true` or `get_setting`. Setting changes are available to the model through `agent_harness` only when the user explicitly asks. `model_routing` is read-only; model/provider selection, catalog refresh, pin/unpin, custom provider edits, and route setting changes stay visible picker, settings, workspace, or slash-command flows. Secret-backed provider or channel values are stored through the secret manager and displayed as redacted references.
+Setting discovery is compact by default through `settings action:"list"` and full with `includeParameters:true` or `settings action:"get"`. Setting changes use `settings action:"set|reset"` only when the user explicitly asks and provides confirmation. `models action:"status|route|local|providers|provider"` is read-only; `models action:"smoke"` is confirmation-gated. Model/provider selection, catalog refresh, pin/unpin, custom provider edits, and route setting changes stay visible picker, settings, workspace, or slash-command flows. Secret-backed provider or channel values are stored through the secret manager and displayed as redacted references.
 
 ## Related Docs