@pellux/goodvibes-agent 1.0.31 → 1.0.33

package/docs/README.md

@@ -19,10 +19,10 @@ Important baseline constraints:
 - Agent installs one executable: `goodvibes-agent`.
 - Current package version is recorded in `package.json`; the top `CHANGELOG.md` section is the latest completed `1.0.x` release in this tree.
 - Agent uses Bun `1.3.10` or newer and TypeScript-authored source.
-- Agent depends on `@pellux/goodvibes-sdk@0.33.35`.
+- Agent depends on `@pellux/goodvibes-sdk@0.33.36`.
 - Agent connects to a GoodVibes host owned outside this product.
 - Agent does not start, stop, restart, install, uninstall, or own the connected GoodVibes host.
-- User-facing Agent workspace categories/actions, single workspace-action lookup/execution, built-in panels and single-panel lookup, modal/overlay/picker UI surfaces and single-surface lookup, named operator surfaces, top-level CLI mirrors and single-mirror lookup with preferred model routes, fixed shortcuts, configurable keybindings, single-keybinding lookup, shell-safe keybinding execution, slash commands, single-command lookup with effect, boundary, and preferred-route policy metadata, model tools with optional schema inlining and individual model tool schemas, settings catalog filtering and single-setting lookup, local registries, connected-host capability boundaries, single connected-host capability inspection, and live connected-host readiness are model-visible through Agent-owned tools. Visible UI routing includes the command browser, reasoning-effort picker, live process output, runtime activity, settings, workspaces, and pickers the user can open. Every workspace editor descriptor reports model-execution route metadata, and local memory, note, persona, skill, and routine create editors can also run through confirmed workspace actions. Mutations, visible UI routing, and keybinding execution remain explicit and confirmation-gated; prompt-editor-only shortcuts stay direct user interaction; and ambiguous lookup matches are refused with candidates instead of guessed.
+- User-facing Agent workspace categories/actions, single workspace-action lookup/execution, built-in panels and single-panel lookup, modal/overlay/picker UI surfaces and single-surface lookup, named operator surfaces, top-level CLI mirrors and single-mirror lookup with preferred model routes, fixed shortcuts, configurable keybindings, single-keybinding lookup, shell-safe keybinding execution, slash commands, single-command lookup with effect, boundary, and preferred-route policy metadata, channel readiness summary/search/single-channel lookup, redacted notification target summary/search/single-target lookup, provider account summary/search/single-provider lookup, MCP server summary/search/single-server lookup with trust, role, quarantine, and tool inventory posture, setup/onboarding posture summary/search/single-item lookup, provider/model routing posture summary/search/single-route-or-model lookup, pairing posture summary/search/single-route lookup, delegation posture summary/search/single-route lookup, security posture summary/search/single-finding lookup, support/auth/trust/subscription/voice bundle route discovery and redacted bundle inspection, voice/media posture summary/search/single-provider lookup, session/bookmark posture summary/search/single-session lookup, compact model tools with optional schema inlining and individual model tool schemas, release evidence bundle summary/search/single-artifact lookup, release-readiness inventory summary/search/single-item lookup, settings catalog filtering and single-setting lookup, local registries, public operator method catalog, single operator method inspection, service endpoint posture, single service endpoint inspection, connected-host capability boundaries, single connected-host capability inspection, and live connected-host readiness are model-visible through Agent-owned tools. Visible UI routing includes the command browser, reasoning-effort picker, live process output, runtime activity, settings, workspaces, and pickers the user can open. Every workspace editor descriptor reports model-execution route metadata, and local memory, note, persona, skill, and routine create editors can also run through confirmed workspace actions. Mutations, visible UI routing, keybinding execution, channel delivery, notification delivery, provider auth changes, setup apply/import/profile changes, provider/model selection/refresh/favorite/custom-provider changes, pairing/manual-token/companion connection changes, delegation submissions, security/trust/bundle export-import changes, voice/media generation and voice toggle changes, session/bookmark save/resume/export/delete changes, and MCP server configuration/trust/role/quarantine changes remain explicit and confirmation-gated; prompt-editor-only shortcuts stay direct user interaction; and ambiguous lookup matches are refused with candidates instead of guessed.
 - Agent Knowledge uses only `/api/goodvibes-agent/knowledge/*`; there is no default knowledge or non-Agent product fallback.
 - Agent supports isolated Agent homes with `GOODVIBES_AGENT_HOME=<path>` and named profile homes with `goodvibes-agent profiles create <name> --template <starter> --yes` plus `--agent-profile <name>`.
 - Agent supports connected-host URL overrides with `--runtime-url http://host:port` or `GOODVIBES_AGENT_RUNTIME_URL=http://host:port`; these only change the Agent connection target.

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

@@ -17,7 +17,11 @@ Agent channel UX should show:
 
 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`.
 
-The model can inspect channel-facing workspace actions with `agent_harness`, and it can send one explicit configured delivery through `agent_channel_send` 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 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 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`. Those readiness modes are read-only: they return setup state, delivery posture, risk labels, safe config-key names, default-target key names, and preferred model routes 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 configured notification target posture with `agent_harness` mode `notifications`, and inspect one redacted target with mode `notification_target` using `notificationTargetId`, `target`, or `query`. Those notification modes return target count, validity, protocol/host posture, fingerprints, and management route hints, 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
 
@@ -43,7 +47,7 @@ Use public SDK/operator routes only. For Agent Knowledge, the only valid family
 /api/goodvibes-agent/knowledge/*
 ```
 
-If an Agent-specific route is missing, fail closed or show guidance. Do not substitute the default knowledge, another product segment, or private connected-host files.
+If an Agent-specific route is missing, fail closed or show guidance. Do not substitute the default knowledge, another product segment, or private connected-host files. If an Agent-specific route returns default scope metadata, treat that as contamination and fail the call.
 
 Harness and settings operations use the Agent-owned `agent_harness` tool. Generic settings/context mutators are not the model-facing Agent contract.
 

package/docs/connected-host.md

@@ -19,9 +19,24 @@ Start the owning GoodVibes host before launching Agent. Agent expects that host
 
 ```text
 http://127.0.0.1:3421
-/api/goodvibes-agent/knowledge/status
-/api/goodvibes-agent/knowledge/ask
-/api/goodvibes-agent/knowledge/search
+GET  /api/goodvibes-agent/knowledge/status
+POST /api/goodvibes-agent/knowledge/ask
+POST /api/goodvibes-agent/knowledge/search
+GET  /api/goodvibes-agent/knowledge/sources
+GET  /api/goodvibes-agent/knowledge/nodes
+GET  /api/goodvibes-agent/knowledge/issues
+GET  /api/goodvibes-agent/knowledge/items/{id}
+GET  /api/goodvibes-agent/knowledge/map
+GET  /api/goodvibes-agent/knowledge/connectors
+GET  /api/goodvibes-agent/knowledge/connectors/{id}
+GET  /api/goodvibes-agent/knowledge/connectors/{id}/doctor
+POST /api/goodvibes-agent/knowledge/ingest/url
+POST /api/goodvibes-agent/knowledge/ingest/artifact
+POST /api/goodvibes-agent/knowledge/ingest/urls
+POST /api/goodvibes-agent/knowledge/ingest/bookmarks
+POST /api/goodvibes-agent/knowledge/ingest/browser-history
+POST /api/goodvibes-agent/knowledge/ingest/connector
+POST /api/goodvibes-agent/knowledge/reindex
 ```
 
 If the GoodVibes API is on a different host or port, use a one-off override when launching the TUI:
@@ -54,10 +69,16 @@ Agent owns the operator assistant TUI, local profiles, local memory/notes/routin
 
 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 model can inspect this boundary with `agent_harness` mode `connected_host`. That report includes the configured base URL, token presence, token path, allowed route families, first-class Agent tool capabilities, tool availability, and blocked capabilities. Allowed capabilities are limited to 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`; it returns either the allowed capability with related route families or the blocked capability with the boundary reason.
+The model can inspect this boundary with `agent_harness` mode `connected_host`. That report includes the configured base URL, token presence, token path, allowed route families, first-class Agent tool capabilities, tool availability, and blocked capabilities. Allowed capabilities include read-only operator briefing, explicit allowlisted approval/automation/schedule actions, isolated Agent Knowledge status/ask/search/source/node/issue/item/map/connector reads, isolated Agent Knowledge 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`; it returns either the allowed capability with related route families or the blocked capability with the boundary reason.
+
+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 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. To inspect one endpoint without parsing the full report, 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 live connected-host readiness with `agent_harness` mode `connected_host_status`. That report uses the same read-only status probe as the CLI: it checks the connected-host status route, verifies the SDK version pin, checks the isolated Agent Knowledge status route when token and version posture allow it, reports endpoint bindings and token posture without printing token values, and returns actionable findings. It is diagnostic only and does not expose host start, stop, restart, install, listener, or account-management operations.
 
-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.
+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.
+
+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 also rejects successful-looking responses that expose default scope metadata or 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.

package/docs/getting-started.md

@@ -5,7 +5,7 @@ GoodVibes Agent is the installable `1.0.x` personal operator assistant built on
 ## Requirements
 
 - Bun `1.3.10` or newer
-- A connected GoodVibes host compatible with `@pellux/goodvibes-sdk@0.33.35`
+- A connected GoodVibes host compatible with `@pellux/goodvibes-sdk@0.33.36`
 - A token/config path accepted by the connected host
 
 Agent does not launch the connected host for you.
@@ -44,7 +44,13 @@ After setup has been applied once, the TUI opens directly into the Agent operato
 
 Press `/` inside the Agent workspace to search every workspace action by name, category, command, or detail. Use that finder before reaching for shell commands; CLI subcommands are scriptable mirrors of these TUI workflows.
 
-The model can inspect and use the same harness surface through Agent-owned tools. `agent_harness` exposes workspace category discovery, workspace action discovery, single workspace-action inspection and execution by action id, command, or lookup text, built-in panel discovery/routing by panel id or lookup text, modal/overlay/picker UI surface discovery/routing by surface id or lookup text, top-level CLI mirror discovery and single-mirror lookup by command string, command token, or lookup text, fixed shortcut and configurable keybinding discovery, keybinding inspection/mutation by action id or lookup text, confirmation-gated shell-safe keybinding execution, slash-command discovery, single slash-command inspection by typed command or lookup text, concrete built-in command effect, boundary, and preferred-route policy metadata, single slash-command execution by typed command or lookup text with confirmation, model tool discovery with optional schema inlining and single-tool schema inspection, settings catalog filtering plus inspection/mutation by key or lookup text, connected-host capability inventory, single connected-host capability inspection, and live connected-host readiness posture. CLI mirror modes are read-only catalog/parser inspection and point the model to the matching in-process tool, workspace action, setting mode, slash-command mirror, or current-conversation response route. Panel modes expose catalog/open state and route visible panel/workspace changes through the current Agent shell bridge with confirmation. UI surface modes expose help, shortcuts, command browser, conversation search, prompt-history search, slash-command mode, file picker, block actions, context, runtime activity, live process output, bookmarks, model/provider/reasoning-effort pickers, TTS provider/voice pickers, session/profile pickers, the panel-picker compatibility route, security/knowledge/subscription operator surfaces, settings, MCP workspace, onboarding, and Agent workspace entrypoints; `open_ui_surface` is confirmation-gated and only performs visible shell navigation. Shortcut modes expose the fixed runtime/editor shortcuts and the live keybindings table; keybinding descriptors include a model operation route, `run_keybinding` executes supported shell-safe equivalents only with confirmation, prompt-editor-only or terminal-selection shortcuts remain direct user interaction, and confirmed keybinding edits write the same `keybindings.json` file the user edits and reload the runtime manager. Workspace action discovery can include editor field schemas with `includeParameters:true`, including starter-template defaults for profile creation and selected-routine defaults for routine schedule promotion when `recordId` is supplied; model tool discovery can include JSON schemas with `includeParameters:true`; every editor descriptor reports `modelExecution` route metadata, and single-action lookup and execution use the same user-facing search fields, return lookup metadata where the action result carries descriptors, and refuse ambiguous run requests with candidates. Single-CLI-mirror, single-panel, single-surface, single-keybinding, single-slash-command, single-tool, single-setting, and single-connected-host-capability lookup use their catalog search fields, return lookup metadata where the result carries it, and refuse ambiguous route, schema, capability, or mutation requests with candidates; confirmed slash-command execution uses the same slash-command lookup and refuses ambiguous requests before any handler runs. Selection-based local workspace actions accept a local `recordId`, so the model can use the same note promotion and local registry flows as the TUI. Direct local create editors for memory, notes, personas, skills, and routines can execute from submitted fields through `run_workspace_action` and `agent_local_registry` with confirmation. Command-backed editor forms execute through the shared slash-command registry with confirmation, and web research/fetch forms return the main-conversation prompt for the model to use directly. First-class model tools cover the main product workflows directly: Agent Knowledge, Agent Knowledge ingest, Agent-local memory/notes/personas/skills/routines, operator actions, notifications, channel sends, reminders, generated media, and work plans.
+The model can inspect and use the same harness surface through Agent-owned tools. `agent_harness` exposes workspace category discovery, workspace action discovery, single workspace-action inspection and execution by action id, command, or lookup text, built-in panel discovery/routing by panel id or lookup text, modal/overlay/picker UI surface discovery/routing by surface id or lookup text, top-level CLI mirror discovery and single-mirror lookup by command string, command token, or lookup text, fixed shortcut and configurable keybinding discovery, keybinding inspection/mutation by action id or lookup text, confirmation-gated shell-safe keybinding execution, slash-command discovery, single slash-command inspection by typed command or lookup text, concrete built-in command effect, boundary, and preferred-route policy metadata, single slash-command execution by typed command or lookup text with confirmation, channel readiness discovery and single-channel inspection by id or lookup text, redacted notification target discovery and single-target inspection by id or lookup text, provider account discovery and single-account inspection by provider id or lookup text, MCP server discovery and single-server inspection by id or lookup text, setup/onboarding posture discovery and single setup-item inspection by id or lookup text, provider/model routing discovery and single route-or-model inspection by id or lookup text, companion pairing posture discovery and single pairing-route inspection by id or lookup text, explicit build-delegation posture discovery and single delegation-route inspection by id or lookup text, redacted security posture discovery and single-finding inspection by id or lookup text, support/auth/trust/subscription/voice bundle route discovery and redacted existing-bundle inspection by path, voice/media readiness discovery and single-provider inspection by id or lookup text, session/bookmark posture discovery and single saved-session inspection by id or lookup text, compact model tool discovery with optional schema inlining and single-tool schema inspection, release evidence bundle discovery with summary, search, and single-artifact lookup, release-readiness inventory discovery with summary, search, and single-item lookup, settings catalog filtering plus inspection/mutation by key or lookup text, public operator method catalog and single-method inspection, service posture and single-endpoint inspection, connected-host capability inventory, single connected-host capability inspection, and live connected-host readiness posture.
+
+CLI mirror modes are read-only catalog/parser inspection and point the model to the matching in-process tool, workspace action, setting mode, slash-command mirror, or current-conversation response route. Panel modes expose catalog/open state and route visible panel/workspace changes through the current Agent shell bridge with confirmation. UI surface modes expose help, shortcuts, command browser, conversation search, prompt-history search, slash-command mode, file picker, block actions, context, runtime activity, live process output, bookmarks, model/provider/reasoning-effort pickers, TTS provider/voice pickers, session/profile pickers, the panel-picker compatibility route, security/knowledge/subscription operator surfaces, settings, MCP workspace, onboarding, and Agent workspace entrypoints; `open_ui_surface` is confirmation-gated and only performs visible shell navigation. Shortcut modes expose the fixed runtime/editor shortcuts and the live keybindings table; keybinding descriptors include a model operation route, `run_keybinding` executes supported shell-safe equivalents only with confirmation, prompt-editor-only or terminal-selection shortcuts remain direct user interaction, and confirmed keybinding edits write the same `keybindings.json` file the user edits and reload the runtime manager.
+
+Workspace action discovery can include editor field schemas with `includeParameters:true`, including starter-template defaults for profile creation and selected-routine defaults for routine schedule promotion when `recordId` is supplied; model tool discovery can include JSON schemas with `includeParameters:true`; channel readiness discovery can include target-shape hints with `includeParameters:true`; notification target discovery can include management-route hints with `includeParameters:true`; provider account discovery can include login/logout route hints with `includeParameters:true`; MCP server discovery can include per-server tool inventory with `includeParameters:true`; setup posture discovery can include model route hints with `includeParameters:true`; model routing discovery can include mutation-route hints with `includeParameters:true`; pairing posture discovery can include connected-host/channel route hints with `includeParameters:true`; delegation posture discovery can include delegation route hints with `includeParameters:true`; security posture discovery can include finding detail with `includeParameters:true`; support bundle route discovery can include route parameter hints with `includeParameters:true`; voice/media posture discovery can include model route hints with `includeParameters:true`; session discovery can include saved-session file paths and search snippets with `includeParameters:true`; release evidence discovery can include artifact source/data with `includeParameters:true`; release-readiness discovery can include source and quality detail with `includeParameters:true`; operator method discovery can include parameter hints with `includeParameters:true`; service posture discovery can include reachability probes and redacted log tail with `includeParameters:true`; every editor descriptor reports `modelExecution` route metadata, and single-action lookup and execution use the same user-facing search fields, return lookup metadata where the action result carries descriptors, and refuse ambiguous run requests with candidates.
+
+Single-CLI-mirror, single-panel, single-surface, single-keybinding, single-slash-command, single-channel, single-notification-target, single-provider-account, single-MCP-server, single-setup-item, single-model-route-or-model, single-pairing-route, single-delegation-route, single-security-finding, single-support-bundle, single-voice-media-provider, single-saved-session, single-tool, single-release-evidence-artifact, single-release-readiness-item, single-operator-method, single-service-endpoint, single-setting, and single-connected-host-capability lookup use their catalog search fields, return lookup metadata where the result carries it, and refuse ambiguous route, schema, capability, or mutation requests with candidates; confirmed slash-command execution uses the same slash-command lookup and refuses ambiguous requests before any handler runs. Selection-based local workspace actions accept a local `recordId`, so the model can use the same note promotion and local registry flows as the TUI. Direct local create editors for memory, notes, personas, skills, and routines can execute from submitted fields through `run_workspace_action` and `agent_local_registry` with confirmation. Command-backed editor forms execute through the shared slash-command registry with confirmation, and web research/fetch forms return the main-conversation prompt for the model to use directly. First-class model tools cover the main product workflows directly: Agent Knowledge status/ask/search, source/node/issue lists, item lookup, map summary, connector list/detail/doctor, Agent Knowledge ingest, Agent-local memory/notes/personas/skills/routines, operator actions, notifications, channel sends, reminders, generated media, and work plans.
 
 Use the Artifacts area for concrete files and generated output: attach images to prompts, export conversations or saved sessions, ingest local source files and URL lists into Agent Knowledge, import bookmarks or browser history, inspect source records, and generate media artifacts from confirmed prompts.
 
@@ -118,7 +124,7 @@ Typed slash commands are available for repeat users, but they are not required f
 
 The active persona plus enabled Agent routines, reviewed memory, and skills are injected into the main serial assistant conversation. Starting a routine records local usage and prints its steps in the main conversation; it does not start background automation. Promoting a routine to a schedule is an explicit `schedules.create` call, requires `--yes`, writes a local redacted promotion receipt, and preserves the rule that Agent Knowledge never falls back to default knowledge or non-Agent knowledge segments.
 
-Use `/channels` inside the TUI for channel readiness and exact confirmed sends. Readiness views show enabled channels, missing config key names, delivery posture, and risk labels without sending messages or rendering token values. Companion pairing is QR-first; `/pair` hides the raw token in text, and manual token display requires `/pair --show-token --yes`. `/channels send --channel <surface[:route[:label]]> --message <text> --yes` sends one explicit delivery through configured strategies.
+Use `/channels` inside the TUI for channel readiness and exact confirmed sends. Readiness views show enabled channels, missing config key names, delivery posture, and risk labels without sending messages or rendering token values. The model can inspect the same readiness map through `agent_harness` modes `channels` and `channel`; delivery still goes through `agent_channel_send` only after an explicit user request. Notification target posture is similarly available through `agent_harness` modes `notifications` and `notification_target`, with webhook values redacted; delivery still goes through `agent_notify` only after an explicit user request. Companion pairing is QR-first; `/pair` hides the raw token in text, and manual token display requires `/pair --show-token --yes`. `/channels send --channel <surface[:route[:label]]> --message <text> --yes` sends one explicit delivery through configured strategies.
 
 The main assistant conversation can perform narrow confirmed operator actions when the user explicitly asks for a specific target: approve/deny/cancel one approval, run/pause/resume one automation job, cancel/retry one automation run, or run one schedule. Those calls use only public connected-host routes, require confirmation, and do not create, edit, or delete automation definitions.
 
@@ -129,16 +135,30 @@ When the main assistant conversation needs to change Agent settings, inspect/cha
 Start the owning GoodVibes host before using connected Agent features. Agent expects that host to expose the public operator/Agent routes, including:
 
 - `GET /status`
-- `/api/goodvibes-agent/knowledge/status`
-- `/api/goodvibes-agent/knowledge/ask`
-- `/api/goodvibes-agent/knowledge/search`
-- `/api/goodvibes-agent/knowledge/ingest/url`
+- `GET /api/goodvibes-agent/knowledge/status`
+- `POST /api/goodvibes-agent/knowledge/ask`
+- `POST /api/goodvibes-agent/knowledge/search`
+- `GET /api/goodvibes-agent/knowledge/sources`
+- `GET /api/goodvibes-agent/knowledge/nodes`
+- `GET /api/goodvibes-agent/knowledge/issues`
+- `GET /api/goodvibes-agent/knowledge/items/{id}`
+- `GET /api/goodvibes-agent/knowledge/map`
+- `GET /api/goodvibes-agent/knowledge/connectors`
+- `GET /api/goodvibes-agent/knowledge/connectors/{id}`
+- `GET /api/goodvibes-agent/knowledge/connectors/{id}/doctor`
+- `POST /api/goodvibes-agent/knowledge/ingest/url`
+- `POST /api/goodvibes-agent/knowledge/ingest/artifact`
+- `POST /api/goodvibes-agent/knowledge/ingest/urls`
+- `POST /api/goodvibes-agent/knowledge/ingest/bookmarks`
+- `POST /api/goodvibes-agent/knowledge/ingest/browser-history`
+- `POST /api/goodvibes-agent/knowledge/ingest/connector`
+- `POST /api/goodvibes-agent/knowledge/reindex`
 
 If the GoodVibes API is not on `http://127.0.0.1:3421`, pass `--runtime-url http://host:port` for a one-off TUI launch or set `GOODVIBES_AGENT_RUNTIME_URL=http://host:port` before launching the TUI.
 
-Agent Knowledge is an Agent-owned product segment. Agent commands must not fall back to default knowledge or other product-specific knowledge spaces.
+Agent Knowledge is an Agent-owned product segment. Agent commands must not fall back to default knowledge or other product-specific knowledge spaces. Successful responses that expose default-scope metadata are treated as scope contamination and fail closed.
 
-Host lifecycle commands are not part of GoodVibes Agent. Use Agent Workspace -> Home -> Host compatibility, Doctor diagnostics, and Review health for diagnostics. CLI status/doctor/compat commands are scriptable mirrors for install checks. The model-visible `connected_host` harness report lists usable Agent route families, first-class tool capabilities, and blocked lifecycle/non-Agent surfaces. `connected_host_capability` inspects one allowed or blocked connected-host capability and returns the matching route families, first-class tools, and boundary reason. The model-visible `connected_host_status` report performs the live read-only connected-host status and isolated Agent Knowledge readiness checks, reports SDK compatibility, token posture, endpoint bindings, route readiness, and actionable findings, and still does not expose host start/stop/restart/install operations.
+Host lifecycle commands are not part of GoodVibes Agent. Use Agent Workspace -> Home -> Host compatibility, Doctor diagnostics, and Review health for diagnostics. CLI status/doctor/compat commands are scriptable mirrors for install checks. The model-visible `service_posture` harness report exposes the same read-only endpoint binding, network-facing posture, issue, and redacted-log diagnostics used by status, doctor, and support bundles; `service_endpoint` inspects one endpoint by `endpointId`, `target`, or `query`. The model-visible `connected_host` harness report lists usable Agent route families, first-class tool capabilities, and blocked lifecycle/non-Agent surfaces. `connected_host_capability` inspects one allowed or blocked connected-host capability and returns the matching route families, first-class tools, and boundary reason. The model-visible `connected_host_status` report performs the live read-only connected-host status and isolated Agent Knowledge readiness checks, reports SDK compatibility, token posture, endpoint bindings, route readiness, and actionable findings, and still does not expose host start/stop/restart/install operations.
 
 ## Current Product Notes
 

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

@@ -26,10 +26,16 @@ GET  /api/goodvibes-agent/knowledge/sources
 GET  /api/goodvibes-agent/knowledge/nodes
 GET  /api/goodvibes-agent/knowledge/issues
 GET  /api/goodvibes-agent/knowledge/items/{id}
+GET  /api/goodvibes-agent/knowledge/map
 GET  /api/goodvibes-agent/knowledge/connectors
+GET  /api/goodvibes-agent/knowledge/connectors/{id}
+GET  /api/goodvibes-agent/knowledge/connectors/{id}/doctor
 POST /api/goodvibes-agent/knowledge/ingest/url
 POST /api/goodvibes-agent/knowledge/ingest/urls
+POST /api/goodvibes-agent/knowledge/ingest/artifact
 POST /api/goodvibes-agent/knowledge/ingest/bookmarks
+POST /api/goodvibes-agent/knowledge/ingest/browser-history
+POST /api/goodvibes-agent/knowledge/ingest/connector
 POST /api/goodvibes-agent/knowledge/reindex
 ```
 
@@ -37,7 +43,9 @@ If those routes are unavailable, Agent commands fail closed with a structured er
 
 The CLI and slash-command layers reject route-selection flags such as `--space`, `--knowledge-space`, `--knowledge-space-id`, and `--include-all-spaces` because those would violate the Agent product boundary.
 
-Agent Knowledge writes are explicit-user-action paths. Slash commands that ingest, import, review issues, reindex, or run consolidation require `--yes`; ask/search/status/list paths remain read-only.
+Successful route responses are validated before rendering. If a connected host response exposes default-scope metadata or carries known non-Agent payload markers, Agent returns a `scope_contamination` error instead of treating that payload as isolated Agent Knowledge.
+
+Agent Knowledge writes are explicit-user-action paths. Slash commands that ingest, import, review issues, reindex, or run consolidation require `--yes`; ask/search/status/list/get/map/connector paths remain read-only.
 
 ## Ask And Search
 
@@ -48,9 +56,9 @@ Use Agent Workspace -> Knowledge -> Ask Agent Knowledge for source-backed Agent
 - sources, titles, and URLs when returned;
 - facts, gaps, and refinement task ids only when the Agent Knowledge route returns them.
 
-`--json` preserves the raw structured Agent route response for tooling.
+`--json` preserves the raw structured Agent route response for tooling after the scope-contamination guard accepts the payload.
 
-The command layer does not turn search results into an answer locally and does not apply client-side filters to hide contamination. Isolation must come from the Agent Knowledge route itself.
+The command layer does not turn search results into an answer locally and does not apply client-side filters to hide contamination. It rejects contaminated payloads; the connected host must still return Agent-owned data for the route to succeed.
 
 Use Agent Workspace -> Knowledge -> Search Agent Knowledge for interactive search. `/knowledge search <query>` and `goodvibes-agent search <query>` query the isolated Agent Knowledge search route and render bounded results with title, id, type, score, source, URL, and snippets when available. Empty Agent stores return an explicit empty state.
 
@@ -60,8 +68,12 @@ Read-only inspection is available from the TUI Knowledge workspace first, with C
 - `/knowledge list --kind sources|nodes|issues`
 - `/knowledge get <id>`
 - `/knowledge connectors`
+- `/knowledge connector <connector-id>`
+- `/knowledge connector-doctor <connector-id>`
 - `/knowledge map`
 
+The main assistant conversation can use the read-only `agent_knowledge` tool for the same isolated status, ask, search, source/node/issue list, item lookup, map, connector list, connector detail, and connector doctor workflows.
+
 ## Ingest
 
 Use Agent Workspace -> Knowledge for URL, URL-list, file, bookmark, browser-history, connector ingest, and reindex forms. The main assistant conversation can also call the confirmed `agent_knowledge_ingest` tool for the same isolated source families. `/knowledge ingest-url <url> --yes` and `goodvibes-agent knowledge ingest-url <url> --yes` ingest URL sources into Agent Knowledge only.
@@ -82,7 +94,7 @@ Artifacts are first-class runtime objects for files, images, audio, video, gener
 
 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 discover the user-facing Knowledge, artifact, research, and media actions with `agent_harness` workspace action modes. When a workspace action maps to a concrete slash command, `agent_harness` can run that command with confirmation. For common product workflows, use the first-class tools first: `agent_knowledge`, `agent_knowledge_ingest`, and `agent_media_generate`.
+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, `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.
 
 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

@@ -19,7 +19,7 @@ The SDK/runtime owns durable storage and route contracts:
 - readiness evaluation and next-question hints;
 - decision records;
 - task, dependency, verification, and assignment metadata;
-- passive operator methods.
+- read-only public operator methods.
 
 Other surfaces can store or inspect planning artifacts, but conversation control stays in Agent. Agent planning state is not default knowledge, another product segment, or arbitrary knowledge data.
 
@@ -70,7 +70,7 @@ The work-plan tracker is for concrete, durable task state after work becomes act
 
 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.
 
-The model can keep the same visible work plan current with `agent_work_plan`. It can also discover `/plan`, `/workplan`, and delegation workspace actions through `agent_harness`; destructive work-plan changes still require explicit user request and confirmation.
+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.
 
 ## Agent Knowledge Boundary
 

package/docs/providers-and-routing.md

@@ -11,7 +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` settings and workspace-action discovery when the model needs to inspect or change Agent-owned routing settings.
+- `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.
+- `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.
 
 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.
 
@@ -40,7 +41,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 changes are available to the model through `agent_harness` only when the user explicitly asks. Secret-backed provider or channel values are stored through the secret manager and displayed as redacted references.
+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.
 
 ## Related Docs
 

package/docs/release-and-publishing.md

@@ -1,17 +1,17 @@
 # Release And Publishing
 
-GoodVibes Agent's current installable `1.0.x` version is recorded in `package.json` and `CHANGELOG.md`.
+GoodVibes Agent's current installable version is recorded in `package.json` and `CHANGELOG.md`.
 
 ## Package Identity
 
 - registry package: `@pellux/goodvibes-agent`
 - executable: `goodvibes-agent`
-- SDK dependency: exact pin to `@pellux/goodvibes-sdk@0.33.35`
+- SDK dependency: exact pin to `@pellux/goodvibes-sdk@0.33.36`
 - runtime: Bun `1.3.10` or newer
 - source language: TypeScript
 - package docs: every Markdown file under `docs/*.md`
 - connected host ownership: outside Agent
-- current release line: `1.0.x`
+- current release line: stable patch releases
 
 End users install and run GoodVibes Agent with Bun:
 
@@ -24,7 +24,11 @@ Do not add non-Bun install instructions for this product. The package is hosted
 
 ## Required Gates
 
-Before any release candidate or patch release:
+The release readiness inventory is the release-quality gate for the current release line. `release/release-readiness.json` must list every release capability that GoodVibes Agent is expected to cover, including capabilities owned by Agent, the connected host, the companion app, and release operations. A bare `covered` status is not enough: every inventory item must also carry `quality` evidence for capability coverage, direct user access, model access through Agent tools or harness routes, safety/product boundary, and release evidence. Package verification rejects any release readiness item that is missing those dimensions or marks them as unknown, todo, gap, unverified, or unproven. The packaged Agent exposes the release evidence bundle through `agent_harness` modes `release_evidence` and `release_evidence_artifact`, and exposes the readiness inventory through `release_readiness` and `release_readiness_item`, so the model can inspect what the user can inspect without relying on hidden project context.
+
+Use neutral evidence aliases in release evidence.
+
+Before any stable release or patch release:
 
 ```sh
 bun install
@@ -46,13 +50,13 @@ Shared release metadata verification requires the `prebuild` and `version` packa
 
 `bun run publish:package` publishes from a staged package directory to the package registry. It re-runs the shared package policy checks against the source tree, filters forbidden package paths during staging, and verifies the staged package docs, required package paths, and metadata before invoking npm. If `NPM_CONFIG_USERCONFIG` is already set, the registry publish command uses it. Otherwise the script creates a temporary 0600 registry userconfig from `NODE_AUTH_TOKEN` or `NPM_TOKEN`, uses it for that publish command, and removes it with the staging directory. The publish script is idempotent for reruns: if the exact package version is already present on the registry, it reports that state and exits successfully instead of failing the release retry. Shared release metadata verification requires those staged source/staged policy checks, forbidden-path filtering, docs checks, auth handoff, idempotent lookup, dry-run pack, public publish, and cleanup markers to remain in the publish script.
 
-`bun run release` requires product release notes instead of raw git-log output. Pass `--notes-file ./release-notes.md` or set `GOODVIBES_AGENT_RELEASE_NOTES` before a real release. For current `1.0.x` patch releases, use product-facing notes that summarize the complete patch contents, not only the first fix in the batch. The original 1.0 release candidate used `--notes-file release/1.0-release-notes.md`, and release metadata verification keeps that artifact with the release readiness and live-verification evidence. Release notes should describe what changed for Agent users: TUI behavior, setup, Agent Knowledge, local behavior libraries, connected-host compatibility, package/install behavior, model-visible harness behavior, and safety policy. Do not use commit hashes as the shipped changelog content.
+`bun run release` requires product release notes instead of raw git-log output. Pass `--notes-file ./release-notes.md` or set `GOODVIBES_AGENT_RELEASE_NOTES` before a real release. For patch releases, use product-facing notes that summarize the complete patch contents, not only the first fix in the batch. Release metadata verification keeps `release/release-notes.md` with the release readiness and live-verification evidence, and package verification requires the installed package to ship the same current release evidence bundle: release notes, performance snapshot, readiness inventory, and live-verification JSON/Markdown. Release notes should describe what changed for Agent users: TUI behavior, setup, Agent Knowledge, local behavior libraries, connected-host compatibility, package/install behavior, model-visible harness behavior, and safety policy. Do not use commit hashes as the shipped changelog content.
 
-Before it mutates version metadata or creates a tag, `bun run release` checks the declared `release/1.0-*` evidence files for existence, non-empty content, final newlines, trailing whitespace, and space-before-tab indentation, then enforces the non-test release gates: typecheck, architecture check, performance check, build, publish check, packed install smoke, verification ledger, pack dry-run, and `git diff --check`. Dry-run previews run the same evidence text hygiene check without writing files, commits, or tags. After it writes the release version, `src/version.ts` fallback, and changelog section, it verifies release metadata and package-facing text policy again, then reruns evidence hygiene and diff hygiene before creating the commit and tag. That package policy check proves `package.json`, `CHANGELOG.md`, and the `src/version.ts` fallback literals agree on the Agent and SDK versions, that the package manifest keeps the required Agent runtime/docs files, exclusions, release/publish script entrypoints, and local CI gate entrypoints without explicitly including forbidden Agent/TUI boundary paths or leaving existing forbidden paths reachable through broad includes, that the local release script still requires product notes, real-release validation, post-mutation package policy, docs staging, and annotated tags, that the GitHub setup action uses the same Bun version as `packageManager`, and that package-facing text is present and still follows Agent docs, rendered CLI help, parser-backed CLI command snippets, parser/type/alias/help/handler/top-level help command coverage, exported package-text source coverage, autocomplete overlay text, context inspector text, in-app help overlays, file/bookmark picker text, live process output text, MCP workspace text, model picker/workspace text, profile/session picker text, process/runtime activity text, search overlays, shared selection/picker chrome, setup/onboarding wizard text, settings workspace text, slash-command registry text, Agent workspace catalog text, route boundaries, install policy, and version pins. The generated changelog heading uses the operator's local release date in `YYYY-MM-DD` form, not UTC rollover time. The prebuild version sync refuses missing, ranged, or otherwise non-exact Agent or SDK versions instead of writing placeholder fallbacks. The release commit stages those metadata files plus every package-facing `docs/*.md` page, so release docs cannot drift outside the tag. The full test suite remains a branch-CI responsibility and must already be green for the release SHA.
+Before it mutates version metadata or creates a tag, `bun run release` checks the declared files under `release/` for existence, non-empty content, final newlines, trailing whitespace, and space-before-tab indentation, then enforces the non-test release gates: typecheck, architecture check, performance check, build, publish check, packed install smoke, verification ledger, pack dry-run, and `git diff --check`. Dry-run previews run the same evidence text hygiene check without writing files, commits, or tags. After it writes the release version, `src/version.ts` fallback, and changelog section, it verifies release metadata and package-facing text policy again, then reruns evidence hygiene and diff hygiene before creating the commit and tag. That package policy check proves `package.json`, `CHANGELOG.md`, and the `src/version.ts` fallback literals agree on the Agent and SDK versions, that the package manifest keeps the required Agent runtime/docs files, exclusions, release/publish script entrypoints, and local CI gate entrypoints without explicitly including forbidden Agent/TUI boundary paths or leaving existing forbidden paths reachable through broad includes, that the local release script still requires product notes, real-release validation, post-mutation package policy, docs staging, and annotated tags, that the GitHub setup action uses the same Bun version as `packageManager`, and that package-facing text is present and still follows Agent docs, rendered CLI help, parser-backed CLI command snippets, parser/type/alias/help/handler/top-level help command coverage, exported package-text source coverage, autocomplete overlay text, context inspector text, in-app help overlays, file/bookmark picker text, live process output text, MCP workspace text, model picker/workspace text, profile/session picker text, process/runtime activity text, search overlays, shared selection/picker chrome, setup/onboarding wizard text, settings workspace text, slash-command registry text, Agent workspace catalog text, route boundaries, install policy, and version pins. The generated changelog heading uses the operator's local release date in `YYYY-MM-DD` form, not UTC rollover time. The prebuild version sync refuses missing, ranged, or otherwise non-exact Agent or SDK versions instead of writing placeholder fallbacks. The release commit stages those metadata files plus every package-facing `docs/*.md` page, so release docs cannot drift outside the tag. The full test suite remains a branch-CI responsibility and must already be green for the release SHA.
 
 `--skip-validation` is only allowed with `--dry-run`. Real releases must run the validation gates above.
 
-`--dry-run` is non-mutating and may be used from a dirty or non-main worktree to preview the next version and generated changelog section. For current `1.0.x` patch previews, use `bun run scripts/release.ts --dry-run --patch --notes-file ./release-notes.md`. The historical 1.0 major cut used `bun run scripts/release.ts --dry-run --major --notes-file release/1.0-release-notes.md`. Real releases still require a clean worktree on `main`.
+`--dry-run` is non-mutating and may be used from a dirty or non-main worktree to preview the next version and generated changelog section. For patch previews, use `bun run scripts/release.ts --dry-run --patch --notes-file ./release-notes.md`. Real releases still require a clean worktree on `main`.
 
 The GitHub release workflow publishes to npm only when the repository variable `PUBLISH_NPM` is `true` and the repository secret `NPM_TOKEN` is configured. Without those repository settings, the workflow still validates and creates the GitHub release, but npm publish must be run from a local environment with an exported token. After optional npm publish, the workflow installs the exact registry version into an isolated Bun home, seeds a connected-host token sentinel, captures stdout and stderr for `--version`, `--help`, and `status --json`, and fails without printing that sentinel. Shared release metadata verification requires those publish, exact-version registry lookup, install smoke, and token-sentinel markers to remain in the release workflow.
 
@@ -64,11 +68,11 @@ Shared release metadata verification requires branch CI to run the compiled bina
 
 Shared release metadata verification requires `architecture:check` to keep the Agent/TUI product-boundary rules: no runtime imports from `goodvibes-tui/src`, no coding-TUI git/worktree header posture in the Agent shell, isolated Agent Knowledge client/routes, typed operator contracts, explicit dependency ownership, source-size limits, and no explicit `any` or process-global test mocks.
 
-Shared release metadata verification requires `perf:check` to load `release/1.0-performance-snapshot.json`, validate its render samples and extra SLO/queue/tool/compaction/integration metrics, run the CI performance-budget evaluation, print the formatted report, and exit from the budget result. The 1.0 performance snapshot is staged with release metadata so the tag carries the exact non-live fixture used by the branch-CI performance gate.
+Shared release metadata verification requires `perf:check` to load `release/performance-snapshot.json`, validate its render samples and extra SLO/queue/tool/compaction/integration metrics, run the CI performance-budget evaluation, print the formatted report, and exit from the budget result. The release performance snapshot is staged with release metadata so the tag carries the exact non-live fixture used by the branch-CI performance gate.
 
-Shared release metadata verification requires `verification:ledger` to keep JSON and Markdown evidence output plus inventory coverage for settings schema, feature flags, slash commands, built-in panels, top-level CLI commands, external surfaces, and onboarding capability bundles, including local-signal, local-behavior, and external-outcome accounting.
+Shared release metadata verification requires `verification:ledger` to keep JSON and Markdown evidence output plus inventory coverage for settings schema, feature flags, slash commands, built-in panels, top-level CLI commands, external surfaces, onboarding capability bundles, the model-visible release evidence bundle, the model-visible service posture surface, the model-visible channel readiness surface, the model-visible notification target surface, the model-visible provider account surface, the model-visible MCP server surface, the model-visible setup/onboarding surface, the model-visible model routing surface, the model-visible pairing surface, the model-visible delegation surface, the model-visible security/support bundle surface, the model-visible voice/media posture surface, the model-visible sessions/bookmarks surface, the model-visible operator method catalog, and the release quality readiness dimensions from `release/release-readiness.json`, including local-signal, local-behavior, and external-outcome accounting. Package verification also enforces compact model tool registration and schema descriptions so tool metadata stays usable.
 
-Shared release metadata verification requires `verification:live` to keep the external-outcome audit for release candidates and real releases: compiled CLI checks, connected-host token/URL discovery, connected-host status/health/model routes, isolated Agent Knowledge status/ask/search routes, SDK-version mismatch skip policy, JSON/Markdown report artifacts, strict mode, and Agent Knowledge contamination guards.
+Shared release metadata verification requires `verification:live` to keep the external-outcome audit for stable releases: compiled CLI checks, connected-host token/URL discovery, connected-host status/health/model routes, isolated Agent Knowledge status/ask/search/source/node/issue/map/connector route checks plus packaged evidence for item inspection, SDK-version mismatch skip policy, JSON/Markdown report artifacts, strict mode, and Agent Knowledge contamination guards.
 
 Do not add targeted `bun test` passes or separate release-only test gates to CI, release, or aggregate scripts. Tests that matter for release must be included in the single full branch-CI suite.
 
@@ -103,4 +107,4 @@ Do not ship connected-host binaries from this package. If Agent later gets compi
 
 ## Product Rule
 
-The `1.0.x` line can include mature terminal foundation code, but package-facing behavior must follow Agent product policy. Follow-up patch releases should continue pruning or reshaping coding-first surfaces while preserving the renderer, input, fullscreen workspace, command registry, and release foundation.
+Stable patch releases can include mature terminal foundation code, but package-facing behavior must follow Agent product policy. Follow-up patch releases should continue pruning or reshaping coding-first surfaces while preserving the renderer, input, fullscreen workspace, command registry, and release foundation.

package/docs/tools-and-commands.md

@@ -41,16 +41,26 @@ Host-management and coding-first commands that would imply connected-host lifecy
 
 ## Model-Visible Harness Surface
 
-The main Agent model has an Agent-owned harness bridge rather than generic SDK settings/context control. Use these model tools as the supported parity layer:
+The main Agent model has an Agent-owned harness bridge rather than generic SDK settings/context control. Use these model tools as the supported model-access layer:
 
-- `agent_harness`: inspect workspace categories/actions and inspect or run one workspace action by action id, command, or lookup text, inspect built-in panels and one panel by id or lookup text, inspect modal/overlay/picker UI surfaces and named operator surfaces by id or lookup text, inspect top-level CLI mirrors and one mirror by command string, command token, or lookup text, inspect fixed shortcuts and configurable keybindings, inspect/change/run one keybinding by action id or lookup text where a shell-safe model route exists, inspect slash commands and one slash command by typed command or lookup text with policy metadata, run concrete slash-command mirrors with confirmation, inspect model tools or one model tool schema, inspect or change Agent settings by exact key or lookup text, inspect connected-host capability boundaries or one connected-host capability, and inspect live connected-host readiness.
+- `agent_harness`: inspect workspace categories/actions and inspect or run one workspace action by action id, command, or lookup text, inspect built-in panels and one panel by id or lookup text, inspect modal/overlay/picker UI surfaces and named operator surfaces by id or lookup text, inspect top-level CLI mirrors and one mirror by command string, command token, or lookup text, inspect fixed shortcuts and configurable keybindings, inspect/change/run one keybinding by action id or lookup text where a shell-safe model route exists, inspect slash commands and one slash command by typed command or lookup text with policy metadata, run concrete slash-command mirrors with confirmation, inspect channel readiness or one channel by id or lookup text, inspect redacted notification targets or one target by id or lookup text, inspect provider account posture or one provider by id or lookup text, inspect MCP server posture or one server by id or lookup text, inspect setup/onboarding posture or one setup item by id or lookup text, inspect provider/model routing or one route/model by id or lookup text, inspect companion pairing posture or one pairing route by id or lookup text, inspect explicit build-delegation posture or one delegation route by id or lookup text, inspect security posture or one finding by id or lookup text, inspect support/auth/trust/subscription/voice bundle routes or one redacted bundle file by path, inspect voice/media readiness or one provider by id or lookup text, inspect session/bookmark posture or one saved session by id or lookup text, inspect compact model tools or one model tool schema, inspect release evidence artifacts, inspect the release-readiness inventory or one readiness item, inspect public operator methods or one operator method, inspect service posture or one service endpoint, inspect or change Agent settings by exact key or lookup text, inspect connected-host capability boundaries or one connected-host capability, and inspect live connected-host readiness.
 - `agent_local_registry`: inspect and maintain Agent-local memory, notes, personas, skills, skill bundles, and routines. Deleting local records requires `confirm:true` and `explicitUserRequest`.
-- `agent_knowledge` and `agent_knowledge_ingest`: ask/search and ingest into the isolated Agent Knowledge segment.
+- `agent_knowledge` and `agent_knowledge_ingest`: inspect status, ask/search, list sources/nodes/issues, inspect items, inspect the map and connectors, and ingest into the isolated Agent Knowledge segment.
 - `agent_operator_briefing` and `agent_operator_action`: inspect connected work/approval/automation posture, or run exact confirmed approval/automation actions.
 - `agent_work_plan`: keep the visible Agent-local work plan current from the conversation.
 - `agent_channel_send`, `agent_notify`, `agent_reminder_schedule`, and `agent_media_generate`: perform confirmed external delivery, notification, reminder, or media actions when the user explicitly asks.
 
-`agent_harness` discovery modes are read-only. `summary` reports the model access map; `workspace` and `workspace_categories` list the Agent workspace category catalog with action counts; `panels` lists the built-in panel catalog, and `panel` resolves one panel by `panelId`, `target`, or `query` with current open/focused state plus its matching Agent workspace route; `ui_surfaces` lists modal, overlay, picker, and workspace entrypoints, and `ui_surface` resolves one by `surfaceId`, `target`, or `query` with shell-opener availability and preferred model routes; `cli_commands` lists top-level package CLI mirror metadata, and `cli_command` resolves one mirror by `cliCommand`, `command`, `commandName`, `target`, or `query`, returning parser output for concrete invocations, blocked command tokens, lookup metadata, and preferred in-process model or current-conversation routes; `shortcuts` returns fixed runtime/editor shortcuts plus configurable keybindings; `keybindings` lists the live resolved keybinding table, and `keybinding`, `run_keybinding`, `set_keybinding`, and `reset_keybinding` resolve one action by `actionId`, `target`, `key`, or `query` with default bindings, custom state, config path, lookup metadata, and model-operation route metadata; `commands` lists slash-command descriptions; `command` returns one slash-command detail by `command`, `commandName`, `target`, or `query`, including parsed arguments plus concrete built-in effect/confirmation/preferred-tool/boundary policy metadata for every registered command root, and refuses ambiguous command lookup with candidate commands; `run_command` executes one confirmed slash command using the same `command`, `commandName`, `target`, or `query` resolver and refuses ambiguous command lookup before any handler runs; `workspace_actions` lists Agent workspace actions and can inline editor field schemas with `includeParameters:true`; `workspace_action` and `run_workspace_action` resolve one action by `actionId`, `command`, `target`, or `query`, using the same user-facing action-search fields; inspection returns lookup metadata plus editor schema and `modelExecution` route metadata for every editor action, and execution refuses ambiguous requests with candidate actions before any effect; `tools` lists model tool definitions and can inline JSON schemas with `includeParameters:true`; `tool` returns one model tool schema by `toolName`, `target`, or `query` and refuses ambiguous schema lookup with candidate tools; `settings` returns setting descriptors plus setting policy and accepts `category`, `prefix`, `query`, `includeHidden:true`, and `limit` filters; `get_setting`, `set_setting`, and `reset_setting` resolve one setting by `key`, `target`, or `query`, return lookup metadata on success, and refuse ambiguous matches with candidate settings; `connected_host` returns the connected-host route families, allowed capabilities, blocked capabilities, and first-class tool availability; `connected_host_capability` returns one allowed or blocked connected-host capability by `capabilityId`, `target`, or `query` with related route families and boundary text and refuses ambiguous capability lookup with candidates; and `connected_host_status` performs a live read-only check of the connected-host status and Agent Knowledge status routes and reports endpoint bindings, token posture, SDK compatibility, route readiness, and findings without printing token values.
+`agent_harness` discovery modes are read-only. `summary` reports the model access map; `workspace` and `workspace_categories` list the Agent workspace category catalog with action counts; `panels` lists the built-in panel catalog, and `panel` resolves one panel by `panelId`, `target`, or `query` with current open/focused state plus its matching Agent workspace route; `ui_surfaces` lists modal, overlay, picker, and workspace entrypoints, and `ui_surface` resolves one by `surfaceId`, `target`, or `query` with shell-opener availability and preferred model routes; `cli_commands` lists top-level package CLI mirror metadata, and `cli_command` resolves one mirror by `cliCommand`, `command`, `commandName`, `target`, or `query`, returning parser output for concrete invocations, blocked command tokens, lookup metadata, and preferred in-process model or current-conversation routes; `shortcuts` returns fixed runtime/editor shortcuts plus configurable keybindings; `keybindings` lists the live resolved keybinding table, and `keybinding`, `run_keybinding`, `set_keybinding`, and `reset_keybinding` resolve one action by `actionId`, `target`, `key`, or `query` with default bindings, custom state, config path, lookup metadata, and model-operation route metadata; `commands` lists slash-command descriptions; `command` returns one slash-command detail by `command`, `commandName`, `target`, or `query`, including parsed arguments plus concrete built-in effect/confirmation/preferred-tool/boundary policy metadata for every registered command root, and refuses ambiguous command lookup with candidate commands; `run_command` executes one confirmed slash command using the same `command`, `commandName`, `target`, or `query` resolver and refuses ambiguous command lookup before any handler runs; `channels` returns read-only channel readiness with setup state, delivery posture, risk labels, safe config-key names, preferred model routes, and optional target-shape hints through `includeParameters:true`; `channel` returns one channel by `channelId`, `target`, or `query` and refuses ambiguous channel lookup with candidates; `notifications` returns read-only redacted notification target refs with target counts, URL validity, protocol/host posture, fingerprints, and optional management-route hints through `includeParameters:true`; `notification_target` returns one redacted notification target by `notificationTargetId`, `target`, or `query` and refuses ambiguous lookup with candidates; `provider_accounts` returns read-only provider auth route posture with freshness, subscription windows, model counts, issues, recommended actions, and optional login/logout route hints through `includeParameters:true`; `provider_account` returns one provider account by `providerId`, `target`, or `query` and refuses ambiguous lookup with candidates; `mcp_servers` returns read-only server posture with connection, trust mode, role, schema freshness, quarantine posture, safe path/host counts, and optional per-server tool inventory through `includeParameters:true`; `mcp_server` returns one server by `mcpServerId`, `target`, or `query` and refuses ambiguous lookup with candidates; MCP add/remove/reload/trust/role/quarantine mutations stay confirmed workspace or slash-command flows; `security_posture` returns redacted token, policy, MCP, plugin, incident, auth, and bundle-route posture with optional finding detail through `includeParameters:true`; `security_finding` returns one current finding by `findingId`, `target`, or `query` and refuses ambiguous lookup with candidates; `support_bundles` returns support/auth/trust/subscription/voice bundle routes and optional route parameter hints through `includeParameters:true`; `support_bundle` inspects one existing bundle JSON by `bundlePath`, `target`, or `query` and returns only structure, counts, timestamps, and redaction metadata; bundle export/import remains confirmed workspace or slash-command flow; `media_posture` returns read-only voice/media provider readiness, TTS setup, browser-tool posture, artifact availability, safe secret-key names, and optional model routes through `includeParameters:true`; `media_provider` returns one voice or media provider by `mediaProviderId`, `target`, or `query` and refuses ambiguous lookup with candidates; media generation, voice enable/disable, and TTS setting changes remain confirmed first-class tool, settings, workspace, or slash-command flows; `workspace_actions` lists Agent workspace actions and can inline editor field schemas with `includeParameters:true`; `workspace_action` and `run_workspace_action` resolve one action by `actionId`, `command`, `target`, or `query`, using the same user-facing action-search fields; inspection returns lookup metadata plus editor schema and `modelExecution` route metadata for every editor action, and execution refuses ambiguous requests with candidate actions before any effect; `tools` lists model tool definitions and can inline JSON schemas with `includeParameters:true`; `tool` returns one model tool schema by `toolName`, `target`, or `query` and refuses ambiguous schema lookup with candidate tools; `release_evidence` returns the packaged release evidence bundle with summary/search over release notes, performance snapshot, readiness inventory, and live-verification artifacts, with optional artifact source/data through `includeParameters:true`; `release_evidence_artifact` returns one release evidence artifact by `artifactId`, `target`, or `query` and refuses ambiguous artifact lookup with candidates; `release_readiness` returns the packaged release-readiness inventory with summary totals, search filtering, source aliases, required quality dimensions, and optional quality detail through `includeParameters:true`; `release_readiness_item` returns one readiness item by `itemId`, `target`, or `query` and refuses ambiguous item lookup with candidates; `operator_methods` returns the read-only public operator and Agent Knowledge method catalog with preferred first-class model tools and optional parameter hints through `includeParameters:true`; `operator_method` returns one method by `methodId`, `target`, or `query` and refuses ambiguous method lookup with candidates; `service_posture` returns connected service endpoint binding, network-facing posture, issue, and redacted-log diagnostics, with optional reachability probes and redacted log tail through `includeParameters:true`; `service_endpoint` returns one endpoint by `endpointId`, `target`, or `query` and refuses ambiguous endpoint lookup with candidates; `settings` returns setting descriptors plus setting policy and accepts `category`, `prefix`, `query`, `includeHidden:true`, and `limit` filters; `get_setting`, `set_setting`, and `reset_setting` resolve one setting by `key`, `target`, or `query`, return lookup metadata on success, and refuse ambiguous matches with candidate settings; `connected_host` returns the connected-host route families, allowed capabilities, blocked capabilities, and first-class tool availability; `connected_host_capability` returns one allowed or blocked connected-host capability by `capabilityId`, `target`, or `query` with related route families and boundary text and refuses ambiguous capability lookup with candidates; and `connected_host_status` performs a live read-only check of the connected-host status and Agent Knowledge status routes and reports endpoint bindings, token posture, SDK compatibility, route readiness, and findings without printing token values.
+
+`setup_posture` returns the same onboarding snapshot and derived capability flags used by the wizard: setup marker posture, provider route, provider-account counts, subscription counts, local behavior discovery, channel/media/setup signals, auth/session counts, and collection issues, with optional route hints through `includeParameters:true`; `setup_item` returns one setup item by `setupItemId`, `target`, or `query` and refuses ambiguous lookup with candidates. Setup apply, provider auth, starter profile creation, local behavior import/create, channel delivery, and setting writes stay visible workspace, settings, slash-command, or first-class tool flows.
+
+`model_routing` returns read-only provider/model routing posture: current chat provider/model/reasoning effort, selectable models, provider ids, pinned models, context windows, reasoning support, safe route setting keys, and optional mutation-route hints through `includeParameters:true`; `model_route` returns one route or model by `modelRouteId`, `target`, or `query` and refuses ambiguous lookup with candidates. Model/provider selection, model catalog refresh, pin/unpin, custom provider edits, and route setting changes stay visible picker, settings, workspace, or slash-command flows.
+
+`pairing_posture` returns companion pairing readiness, control-plane endpoint binding, pairing surface id, token presence and fingerprint, and pairing route catalog without returning raw tokens or QR payloads, with optional connected-host/channel route hints through `includeParameters:true`; `pairing_route` returns one route by `pairingRouteId`, `target`, or `query` and refuses ambiguous lookup with candidates. QR display, manual token display, companion connection, channel delivery, task, approval, provider/model, and attachment actions stay visible user flows.
+
+`delegation_posture` returns explicit build-delegation route posture, runtime availability, delegated-review policy, main-conversation ownership, and blocked local coding ownership with optional route hints through `includeParameters:true`; `delegation_route` returns one route by `delegationRouteId`, `target`, or `query` and refuses ambiguous lookup with candidates. Delegated work submission remains a visible confirmed workspace or slash-command flow and must preserve the full original user ask.
+
+`sessions` returns current session posture, saved session metadata/search matches, bookmark counts, saved bookmark file counts, and optional saved-session file paths/search snippets through `includeParameters:true`; `session` returns one saved session by `sessionId`, `target`, or `query` and refuses ambiguous lookup with candidates. Save, resume, rename, fork, export, delete, and bookmark writes stay visible workspace or slash-command flows.
 
 `open_ui_surface` is a confirmation-gated visible navigation mode for the same shell surfaces the user can open: Agent workspace, settings, MCP workspace, model/provider/reasoning-effort pickers, TTS provider/voice pickers, session/profile pickers, the panel-picker compatibility route, security/knowledge/subscription operator surfaces, conversation search, prompt-history search, slash-command mode, command browser, file picker, block actions, bookmarks, context inspector, runtime activity monitor, live process output, help, shortcuts, and onboarding. It does not perform hidden operations; use first-class model tools, settings modes, workspace actions, or confirmed slash-command mirrors for actual state changes. Ambiguous UI surface lookup text is refused with candidate surfaces instead of routed.
 
@@ -66,7 +76,7 @@ Setting writes, setting resets, supported keybinding actions, keybinding writes/
 
 Selection-based local workspace actions use the same bridge. `agent_harness` reports the required model tool for each local action; for actions that depend on the TUI selection, call `run_workspace_action` with the selected local `recordId` plus an `actionId`, `command`, `target`, or `query` that resolves to one action. Direct local create editors for memory, notes, personas, skills, and routines can execute from submitted `fields` through `run_workspace_action`; the harness validates required fields, requires `confirm:true` and `explicitUserRequest`, and dispatches through `agent_local_registry`. Command-backed editor forms report their shared slash-command dispatch route, direct learned-behavior/profile forms report their local or command bridge, and web research/fetch forms report that execution returns a main-conversation prompt instead of starting hidden nested work. Note promotion actions can prefill and create memory, personas, skills, routines, or isolated Agent Knowledge URL ingests through the matching first-class model tool. Profile creation schemas include the current runtime starter-template inventory, and routine schedule schemas prefill the selected routine when `recordId` or a `routineId` field matches a local routine.
 
-Use first-class Agent tools before falling back to slash-command mirrors. Slash-command execution is for harness parity and scriptable mirrors, not for bypassing Agent product boundaries.
+Use first-class Agent tools before falling back to slash-command mirrors. Slash-command execution is for scriptable mirror coverage, not for bypassing Agent product boundaries.
 
 The main composer supports inline context references. Type `@path/to/file`, `@path/to/folder`, or `@https://example.test/page` in a normal prompt to add bounded context for that turn. `!@path/to/file` remains the raw file-injection form. These references do not ingest anything into Agent Knowledge unless the user explicitly runs a Knowledge ingest action.
 
@@ -106,7 +116,7 @@ Every registered slash-command root in the Agent TUI is listed here. Aliases res
 | `/help` | Show available commands and keyboard shortcuts. |
 | `/image` | Attach an image file to the next message. |
 | `/keybindings` | List keyboard bindings and the config file path. |
-| `/knowledge` | Use isolated Agent Knowledge sources, graph, review queue, ask/search, ingest, and compact prompt packets. |
+| `/knowledge` | Use isolated Agent Knowledge status, ask/search, source/node/issue lists, item lookup, map, connectors, ingest, reindex, and review queue. |
 | `/load` | Load a saved Agent session. |
 | `/mcp` | Manage MCP servers, trust posture, and tool inventory. |
 | `/media` | Inspect media providers or generate media through configured providers. |
@@ -125,7 +135,7 @@ Every registered slash-command root in the Agent TUI is listed here. Aliases res
 | `/qrcode` | Print companion pairing details and a QR code. |
 | `/quit` | Exit the application. |
 | `/redo` | Redo the last undone conversation turn. |
-| `/refresh-models` | Refresh model catalog, benchmarks, and token limits. |
+| `/refresh-models` | Refresh model catalog, metadata, and token limits. |
 | `/reset` | Clear display and conversation context. |
 | `/retry` | Re-send the last user message, optionally with modified text. |
 | `/routines` | Manage Agent-local routines and explicit routine schedule promotion. |
@@ -158,12 +168,14 @@ Every registered slash-command root in the Agent TUI is listed here. Aliases res
 
 `/knowledge ingest-url <url> --yes` ingests into Agent Knowledge through `/api/goodvibes-agent/knowledge/ingest/url`. Knowledge ingestion, imports, issue review, reindex, and consolidation are Agent-owned mutations and require `--yes`.
 
-The Knowledge workspace exposes status, source library, connector review, ask, search, and confirmed ingest forms. Scriptable equivalents such as `goodvibes-agent knowledge list --kind sources|nodes|issues`, `goodvibes-agent knowledge get <id>`, `goodvibes-agent knowledge connectors`, and `goodvibes-agent knowledge map` are read-only CLI inspection paths over the same isolated Agent route family.
+The Knowledge workspace exposes status, source/node/issue libraries, item lookup, map review, connector list/detail/doctor, ask, search, and confirmed ingest forms. Scriptable equivalents such as `goodvibes-agent knowledge list --kind sources|nodes|issues`, `goodvibes-agent knowledge get <id>`, `goodvibes-agent knowledge map`, `goodvibes-agent knowledge connectors`, `goodvibes-agent knowledge connector <connectorId>`, and `goodvibes-agent knowledge connector-doctor <connectorId>` are read-only CLI inspection paths over the same isolated Agent route family.
 
 Workspace ingest forms are the primary user workflow. Scriptable equivalents such as `goodvibes-agent knowledge import-urls <path> --yes`, `goodvibes-agent knowledge import-bookmarks <path> --yes`, and `goodvibes-agent knowledge reindex --yes` are confirmed Agent Knowledge maintenance paths. They call only `/api/goodvibes-agent/knowledge/*`.
 
 The Agent command layer rejects flags that would route knowledge work into another space, including `--space`, `--knowledge-space`, `--knowledge-space-id`, and `--include-all-spaces`. If Agent Knowledge is unavailable, the command fails closed instead of querying a default store.
 
+Successful Agent Knowledge responses are also checked for scope contamination. If a connected host returns default-scope metadata or known non-Agent payload markers, the CLI and `agent_knowledge` model tool return a `scope_contamination` error instead of formatting the payload as Agent Knowledge.
+
 ## Media Artifacts
 
 Agent Workspace -> Voice & Media is the primary media path. Use `Generate media` for a confirmed form that calls configured media providers and stores outputs as GoodVibes artifacts.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pellux/goodvibes-agent",
-  "version": "1.0.31",
+  "version": "1.0.33",
   "private": false,
   "description": "GoodVibes personal operator assistant TUI with a proactive Agent product brain, isolated Agent Knowledge, local profiles, routines, skills, personas, and explicit build delegation.",
   "type": "module",
@@ -22,7 +22,12 @@
     "tsconfig.json",
     "README.md",
     "CHANGELOG.md",
-    "docs/*.md"
+    "docs/*.md",
+    "release/release-notes.md",
+    "release/performance-snapshot.json",
+    "release/release-readiness.json",
+    "release/live-verification/live-verification.json",
+    "release/live-verification/live-verification.md"
   ],
   "scripts": {
     "dev": "bun run src/main.ts",
@@ -82,7 +87,7 @@
   },
   "dependencies": {},
   "devDependencies": {
-    "@pellux/goodvibes-sdk": "0.33.35",
+    "@pellux/goodvibes-sdk": "0.33.36",
     "sql.js": "^1.14.1",
     "sqlite-vec": "^0.1.9",
     "zustand": "^5.0.12",