@pellux/goodvibes-agent 1.0.34 → 1.0.36

package/docs/README.md

@@ -4,6 +4,7 @@ These are the package-facing docs for the GoodVibes Agent `1.0.x` release line.
 
 ## Current Docs
 
+- [Docs Index](README.md)
 - [Getting Started](getting-started.md)
 - [Connected Host](connected-host.md)
 - [Knowledge, Artifacts, and Multimodal](knowledge-artifacts-and-multimodal.md)
@@ -18,8 +19,8 @@ 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.
-- Current Agent version: `package.json`.
-- SDK pin: exact `@pellux/goodvibes-sdk@0.33.36` version in `package.json`.
+- 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: 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.
@@ -27,13 +28,13 @@ These are the package-facing docs for the GoodVibes Agent `1.0.x` release line.
 
 ## Model Access Baseline
 
-Agent-owned model tools expose the same user-facing harness surfaces:
+Agent-owned model tools expose Agent-controlled product surfaces plus operator/audit inspection routes:
 
-- `agent_harness` for workspace actions, slash commands, settings, panels, UI surfaces, keybindings, tool schemas, service/daemon posture, connected-host capability/status, release evidence, and posture catalogs.
+- `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.
 - `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.
 - `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.
 
-Catalog modes are compact by default. Detailed schemas, route hints, redacted log tail, release artifact data, and editor fields require `includeParameters:true` or a singular inspect mode. 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.
+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

@@ -19,9 +19,9 @@ Agent-local memory, routines, skills, and personas are not automatically broadca
 
 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`. Channel discovery is compact by default. 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 `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 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. 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_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
 
@@ -41,7 +41,7 @@ Agent should not start remote build hosts, manage peer lifecycle, or fan out sep
 
 ## Public API Use
 
-Use public SDK/operator routes only. For Agent Knowledge, the only valid family is:
+Use public connected-host/operator routes only. For Agent Knowledge, the only valid family is:
 
 ```text
 /api/goodvibes-agent/knowledge/*

package/docs/connected-host.md

@@ -53,7 +53,7 @@ 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.
 
-If the connected host is unavailable, unauthenticated, or on an incompatible SDK version, the Agent TUI reports actionable diagnostics without printing token values.
+If the connected host is unavailable, unauthenticated, or incompatible with Agent, the Agent TUI reports actionable diagnostics without printing token values.
 
 Use the TUI first for those checks:
 
@@ -69,13 +69,13 @@ 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`. `daemon` is an alias for the same posture report. By default the report is compact: configured base URL, token posture, ownership, mode hints, and capability counts. Use `includeParameters:true` for full route families, allowed capabilities, blocked capabilities, and first-class Agent tool availability. 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`.
+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 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. 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 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 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. `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.
+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.
 
 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.
 

package/docs/getting-started.md

@@ -5,7 +5,7 @@ GoodVibes Agent is the installable `1.0.x` personal operator assistant TUI for G
 ## Requirements
 
 - Bun `1.3.10` or newer.
-- A connected GoodVibes host compatible with the exact `@pellux/goodvibes-sdk@0.33.36` pin in `package.json`.
+- 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.
@@ -54,11 +54,12 @@ Press `/` inside the Agent workspace to search actions by name, category, comman
 
 ## Model Access
 
-The main Agent model can use the same user-facing harness through Agent-owned tools. Use `agent_harness mode:"summary"` for a compact map, then drill into plural catalogs or single-item inspect modes.
+The main Agent model can use the Agent-controlled harness through Agent-owned tools. Use `agent_harness mode:"summary"` for a compact map, `mode:"modes"` to search every harness mode by task or id, and `mode:"mode"` to inspect one mode contract. Then drill into plural catalogs or single-item inspect modes.
 
 Default discovery is intentionally compact:
 
-- plural modes return ids, labels, counts, safe state, and route hints;
+- plural modes return ids, labels, counts, safe state, effect class, and route hints;
+- workspace action, slash-command, CLI, panel, UI surface, shortcut/keybinding, settings, tool, connected-host posture/status/capability, and operator/audit catalogs include short `modelRoute` or `modelAccess` hints for route choice;
 - singular modes return detailed policy and lookup metadata;
 - `includeParameters:true` adds schemas, editor fields, model routes, parameter hints, release artifact data, redacted log tail, and detail that would be too large for normal discovery.
 
@@ -66,20 +67,25 @@ Common model routes:
 
 | Need | Tool Or Mode |
 | --- | --- |
-| Workspace actions | `agent_harness workspace_actions`, `workspace_action`, `run_workspace_action` |
-| Slash commands | `agent_harness commands`, `command`, `run_command` |
-| Settings | `agent_harness settings`, `get_setting`, `set_setting`, `reset_setting` |
-| Visible UI | `agent_harness panels`, `ui_surfaces`, `open_panel`, `open_ui_surface` |
-| Keybindings | `agent_harness shortcuts`, `keybindings`, `keybinding`, `run_keybinding`, `set_keybinding` |
+| 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"` |
+| 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`, `operator_methods` |
-| Connected host/daemon posture | `service_posture`, `connected_host`, `connected_host_status`, `daemon`, `daemon_status` |
+| 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"` |
 
 All effects require explicit user request and confirmation. Ambiguous lookup is refused with candidates.
 
+Registered tool definitions are intentionally terse. The default model catalog keeps top-level descriptions short, removes nested parameter descriptions, and includes direct harness inspection routes; use `agent_harness mode:"tools"` with `includeParameters:true`, `mode:"tool"`, or the owning harness mode when detailed contracts are needed.
+
 ## Isolated Agent Profiles
 
 Use a separate Agent home for isolated local state:
@@ -118,7 +124,7 @@ Starting a routine records local usage and prints its steps in the main conversa
 
 ## Knowledge And Artifacts
 
-Use Agent Workspace -> Knowledge for source-backed Agent Knowledge. The valid route family is:
+Use Agent Workspace -> Knowledge for source-backed Agent Knowledge. The valid connected-host route family is:
 
 ```text
 /api/goodvibes-agent/knowledge/*
@@ -126,6 +132,8 @@ Use Agent Workspace -> Knowledge for source-backed Agent Knowledge. The valid ro
 
 Agent commands fail closed if the route is unavailable or a successful-looking response exposes default-scope metadata.
 
+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 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.
@@ -159,7 +167,7 @@ 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`. These are read-only and do not expose host lifecycle control.
+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.
 
 ## Current Product Notes
 

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

@@ -71,20 +71,25 @@ Read-only inspection is available from the TUI Knowledge workspace first, with C
 - `/knowledge connector <connector-id>`
 - `/knowledge connector-doctor <connector-id>`
 - `/knowledge map`
+- `/knowledge packet <task...> [--scope <path> ...]`
+- `/knowledge explain <task...> [--scope <path> ...]`
 
 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.
+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.
 
-The TUI workspace exposes the common confirmed ingest and reindex flows. The CLI also exposes Agent-specific batch routes for scripts:
+The TUI workspace exposes the common confirmed ingest, issue-review, consolidation, and reindex flows. The CLI also exposes Agent-specific batch routes for scripts:
 
 - `goodvibes-agent knowledge import-urls <path> --yes`
 - `goodvibes-agent knowledge import-bookmarks <path> --yes`
+- `goodvibes-agent knowledge import-browser-history --yes`
+- `/knowledge review-issue <issueId> <accept|reject|resolve|reopen|edit|forget> --yes`
+- `/knowledge consolidate [light|deep] --yes`
 - `goodvibes-agent knowledge reindex --yes`
 
-All of these commands target `/api/goodvibes-agent/knowledge/*`; none of them call default knowledge.
+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.
 
@@ -94,7 +99,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 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.
+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.
 
 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

@@ -13,7 +13,7 @@ The Agent owns:
 - explicit execution approval;
 - delegation metadata when work needs GoodVibes TUI.
 
-The SDK/runtime owns durable storage and route contracts:
+The connected-host runtime owns durable storage and route contracts:
 
 - planning namespaces such as `project:<projectId>`;
 - readiness evaluation and next-question hints;
@@ -25,12 +25,12 @@ Other surfaces can store or inspect planning artifacts, but conversation control
 
 ## Agent Behavior
 
-The Agent derives a stable `projectId` from the workspace path and passes it to the SDK planning service. Planning artifacts are stored under the matching planning namespace so unrelated workspaces do not share state.
+The Agent derives a stable `projectId` from the workspace path and passes it to the connected-host planning service. Planning artifacts are stored under the matching planning namespace so unrelated workspaces do not share state.
 
 Normal conversation can start planning when the user asks for an execution strategy, dependency graph, verification gates, or delegation handoff. The Agent then:
 
 - prints a concise planning summary in the main transcript;
-- persists the current planning state through public SDK/runtime seams;
+- persists the current planning state through public connected-host runtime routes;
 - records active open questions and user answers;
 - calls readiness evaluation for gaps and the suggested next question;
 - asks one focused question instead of executing prematurely.

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.
-- `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.
+- `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.
 
 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.
 

package/docs/release-and-publishing.md

@@ -6,7 +6,7 @@ GoodVibes Agent's current installable version is recorded in `package.json` and
 
 - registry package: `@pellux/goodvibes-agent`
 - executable: `goodvibes-agent`
-- SDK dependency: exact pin to `@pellux/goodvibes-sdk@0.33.36`
+- connected-host compatibility: checked through public Agent routes
 - runtime: Bun `1.3.10` or newer
 - source language: TypeScript
 - package docs: every Markdown file under `docs/*.md`
@@ -20,11 +20,11 @@ bun add -g @pellux/goodvibes-agent
 goodvibes-agent --help
 ```
 
-Do not add non-Bun install instructions for this product. The package is hosted on the public package registry, but the supported install and smoke path is the normal Bun global command above, followed by `goodvibes-agent` launching the TUI. The package-facing text policy rejects non-Bun Agent install/run snippets, references to other `@pellux/goodvibes-*` packages outside Agent and the SDK, and versioned Agent or SDK package references that drift from `package.json`.
+Do not add non-Bun install instructions for this product. The package is hosted on the public package registry, but the supported install and smoke path is the normal Bun global command above, followed by `goodvibes-agent` launching the TUI. The package-facing text policy rejects non-Bun Agent install/run snippets, references to other `@pellux/goodvibes-*` packages outside Agent support paths, and versioned Agent package references that drift from `package.json`.
 
 ## Required Gates
 
-The release-quality inventory, `release/release-readiness.json`, is the capability gate for the current release line. It 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 inventory 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 inventory through `release_readiness` and `release_readiness_item`, so the model can inspect what the user can inspect without relying on hidden project context.
+The release-quality inventory, `release/release-readiness.json`, is the capability gate for the current release line. It 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 inventory 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 inventory through `release_readiness` and `release_readiness_item`, so the model can inspect the same operator/audit artifacts without relying on hidden project context.
 
 Use neutral evidence aliases in release evidence.
 
@@ -46,13 +46,13 @@ Shared release metadata verification also requires `build:package-runtime` to ke
 
 Shared release metadata verification requires `scripts/bun-compile-compat.ts` to keep the css-tree JSON-import rewrites, jsdom XHR worker and stylesheet path-leak patches, sql.js wasm embedding, idempotent patch skip, unexpected-shape warning, and successful patch diagnostic that keep Bun-compiled Agent runtimes self-contained.
 
-Shared release metadata verification requires the `prebuild` and `version` package scripts to run `scripts/prebuild.ts`; that script must keep the workspace-locked project-surface sync and Bun compile compatibility patch, while `scripts/project-surfaces.ts` must preserve exact semver reads plus `src/version.ts` and README badge synchronization.
+Shared release metadata verification requires the `prebuild` and `version` package scripts to run `scripts/prebuild.ts`; that script must keep the workspace-locked project-surface sync and Bun compile compatibility patch, while `scripts/project-surfaces.ts` must preserve exact package semver reads plus `src/version.ts` and README badge synchronization.
 
 `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 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-quality inventory and live-verification evidence, and package verification requires the installed package to ship the same current release evidence bundle: release notes, performance snapshot, release-quality 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 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.
+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 literal agree on the Agent version, 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 Agent package 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 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.
 
@@ -68,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/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 `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 recorded sample 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, 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 dimensions from `release/release-readiness.json`, including local-signal, local-behavior, and external-outcome accounting. Package verification also enforces compact model tool registration, wrapped tool definitions, harness catalog defaults, and schema descriptions so tool metadata stays usable.
+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, the model-visible command/CLI/tool catalogs, the model-visible keyboard route catalog, the model-visible harness mode catalog, and the release-quality dimensions from `release/release-readiness.json`, including local-signal, local-behavior, and external-outcome accounting. Package verification also enforces compact model tool registration, wrapped tool definitions, harness catalog defaults, searchable harness mode discovery, command/CLI/tool route metadata, keyboard route metadata, connected-host route hints, operator/audit route hints, and stripped nested schema descriptions so tool metadata stays usable.
 
-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.
+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, 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.
 

package/docs/tools-and-commands.md

@@ -19,7 +19,7 @@ High-signal TUI routes:
 | --- | --- |
 | `/agent` | Open the fullscreen operator workspace. |
 | `/help` and `/commands` | Discover registered slash commands. |
-| `/health`, `/compat`, `/auth` | Inspect runtime, SDK, host, and auth posture. |
+| `/health`, `/compat`, `/auth` | Inspect runtime, connected-host, compatibility, and auth posture. |
 | `/model`, `/provider`, `/effort` | Inspect or change provider/model/reasoning routes. |
 | `/knowledge` | Use isolated Agent Knowledge. |
 | `/memory`, `/notes`, `/personas`, `/skills`, `/routines` | Manage Agent-local behavior libraries. |
@@ -34,7 +34,7 @@ High-signal TUI routes:
 
 | Tool | Use |
 | --- | --- |
-| `agent_harness` | Discover and operate user-facing harness surfaces. |
+| `agent_harness` | Discover and operate Agent harness routes, including visible surfaces and operator/audit inspection. |
 | `agent_knowledge` | Read isolated Agent Knowledge: status, ask/search, lists, item, map, connectors. |
 | `agent_knowledge_ingest` | Confirmed ingest into isolated Agent Knowledge. |
 | `agent_local_registry` | Inspect or update Agent-local memory, notes, personas, skills, bundles, and routines. |
@@ -48,30 +48,33 @@ High-signal TUI routes:
 
 ## `agent_harness`
 
-Use `agent_harness mode:"summary"` first. Summary and plural catalog modes are compact by default. They return counts, ids, labels, state, and short route hints. Use `includeParameters:true` or a singular inspect mode when the model needs full schemas, policy detail, editor fields, redacted log tail, release artifact data, route hints, or tool parameters.
+Use `agent_harness mode:"summary"` first. Use `mode:"modes"` to search every harness mode by task, family, effect type, id, alias, or parameter name. Use `mode:"mode"` to inspect one mode contract. Summary and plural catalog modes are compact by default. They return counts, ids, labels, state, effect class, and short `modelRoute` or `modelAccess` hints when a route decision is needed. Use `includeParameters:true` or a singular inspect mode when the model needs full schemas, policy detail, editor fields, redacted log tail, release artifact data, route hints, or tool parameters.
 
 Discovery modes:
 
 | Mode | What It Lists |
 | --- | --- |
+| `summary` | Compact counts, status, and a short guide for where to drill in next. |
+| `modes` | Searchable catalog of every `agent_harness` mode and its task fit. |
 | `workspace`, `workspace_categories`, `workspace_actions` | Workspace categories and actions. |
-| `commands`, `cli_commands` | Slash commands and top-level package CLI mirrors. |
+| `commands`, `cli_commands` | Slash commands and top-level package CLI mirrors with compact policy and route hints. |
 | `panels`, `ui_surfaces` | Built-in panels and visible modal/overlay/picker/workspace surfaces. |
-| `shortcuts`, `keybindings` | Fixed shortcuts and configurable keybindings. |
+| `shortcuts`, `keybindings` | Fixed shortcuts and configurable keybindings with direct route/access metadata. |
 | `settings` | Compact Agent setting rows with category, prefix, query, hidden, and limit filters. |
-| `tools` | First-class model tool definitions; schema details require `includeParameters:true` or `tool`. |
+| `tools` | First-class model tool definitions with compact harness inspection routes; schema details require `includeParameters:true` or `tool`. |
 | `channels`, `notifications` | Channel readiness and redacted notification targets. |
 | `provider_accounts`, `model_routing` | Provider auth and provider/model route posture. |
 | `mcp_servers`, `setup_posture`, `pairing_posture`, `delegation_posture` | MCP, setup, pairing, and build-delegation posture. |
 | `security_posture`, `support_bundles`, `media_posture`, `sessions` | Security, bundle route, voice/media, and session/bookmark posture. |
 | `operator_methods` | Public operator and Agent Knowledge method catalog. |
 | `service_posture`, `connected_host`, `daemon` | Endpoint, connected-host, and daemon alias posture. |
-| `release_evidence`, `release_readiness` | Packaged release evidence and release-quality inventory. |
+| `release_evidence`, `release_readiness` | Operator/audit release artifacts and release-quality inventory. |
 
 Single-item inspect modes:
 
 | Mode | Lookup Fields |
 | --- | --- |
+| `mode` | `target` or `query` |
 | `workspace_action` | `actionId`, `command`, `target`, `query` |
 | `command`, `cli_command` | `command`, `commandName`, `cliCommand`, `target`, `query` |
 | `panel`, `ui_surface`, `keybinding`, `tool` | Exact id/name or `target`/`query` |
@@ -87,7 +90,7 @@ Effect modes:
 
 | Mode | Effect |
 | --- | --- |
-| `run_workspace_action` | Executes one resolved workspace action through the same editor/command/local bridge as the TUI. |
+| `run_workspace_action` | Executes one resolved workspace action through the same editor, command, or local route as the TUI. |
 | `run_command` | Executes one resolved slash command through the shared command registry. |
 | `open_panel`, `open_ui_surface` | Routes visible shell navigation. |
 | `run_keybinding` | Runs supported shell-safe keybinding actions only. |
@@ -96,33 +99,39 @@ Effect modes:
 
 Every effect mode requires `confirm:true` and `explicitUserRequest`. Ambiguous lookups return candidates before any effect runs.
 
+Registered model tool definitions are compact by default. Tool descriptions use short curated summaries or a tight fallback cap, nested JSON-schema descriptions are stripped from the default registered catalog, and catalog rows include direct harness inspection routes. Use `agent_harness mode:"tools"` with `includeParameters:true`, `mode:"tool"`, or a specific harness mode when detailed contracts are needed.
+
 ## Workspace Action Execution
 
-`workspace_action` inspection returns editor schemas and `modelExecution` detail. `workspace_actions` can include the same detail with `includeParameters:true`.
+`workspace_actions` returns compact action rows with short `modelRoute` hints. `workspace_action` inspection returns editor schemas and `modelExecution` detail. `workspace_actions` can include the same detail with `includeParameters:true`.
+
+`panels` returns compact built-in panel rows with workspace route metadata and a short `modelRoute` for visible navigation or matching workspace operation. `panel` inspection adds policy detail and current open/focus state.
+
+`ui_surfaces` returns compact modal, picker, overlay, and workspace rows with a short `modelRoute`. `ui_surface` inspection and `includeParameters:true` add the longer `preferredModelRoute` and confirmation policy.
 
 Execution routes:
 
 - Local memory, notes, personas, skills, routines, and bundles dispatch through `agent_local_registry`.
 - Confirmed Agent Knowledge URL/file/bookmark/browser-history/connector ingest dispatches through `agent_knowledge_ingest`.
 - Command-backed editors dispatch through `run_command`.
-- Learned-behavior and profile creation use the Agent-local or slash-command bridge.
+- Learned-behavior and profile creation use the Agent-local or slash-command route.
 - Web research/fetch forms return a main-conversation prompt instead of starting hidden nested work.
 - Selection-based actions accept `recordId` so the model can use the same selected-record flows as the TUI.
 
 ## Settings And Keybindings
 
-Settings discovery accepts `category`, `prefix`, `query`, `includeHidden:true`, and `limit`. It is compact by default; use `includeParameters:true` or `get_setting` for full descriptions/defaults. Single setting reads/writes resolve by `key`, `target`, or `query`; ambiguous matches are refused. Secret-backed setting writes store raw values through the secret manager and return redacted output. Connected-host lifecycle/listener settings are read-only in Agent.
+Settings discovery accepts `category`, `prefix`, `query`, `includeHidden:true`, and `limit`. It is compact by default and each row includes a short `modelRoute` that distinguishes read-only settings from set/reset-capable settings; use `includeParameters:true` or `get_setting` for full descriptions/defaults. Single setting reads/writes resolve by `key`, `target`, or `query`; ambiguous matches are refused. Secret-backed setting writes store raw values through the secret manager and return redacted output. Connected-host lifecycle/listener settings are read-only in Agent.
 
-Keybinding discovery returns fixed shortcuts plus the live resolved binding table. `run_keybinding` only executes actions with faithful current-shell routes. Prompt-editor-only shortcuts, terminal text selection, category cycling, and reserved shortcuts stay direct user interaction.
+Keybinding discovery returns fixed shortcuts plus the live resolved binding table. Fixed shortcuts and configurable bindings include direct `modelRoute` and `modelAccess` metadata so the model can distinguish supported harness routes from direct-user-only controls. `run_keybinding` only executes actions with faithful current-shell routes. Prompt-editor-only shortcuts, terminal text selection, category cycling, and reserved shortcuts stay direct user interaction.
 
 ## Connected Host And Daemon
 
 The connected host is external. Agent can inspect it through:
 
 - `service_posture` and `service_endpoint` for endpoint binding, network-facing posture, issues, optional probes, and redacted log tail.
-- `connected_host` and `daemon` for compact connected-host posture; use `includeParameters:true` for route families, allowed capabilities, blocked lifecycle/non-Agent surfaces, and first-class tool availability.
-- `connected_host_capability` for one allowed or blocked capability.
-- `connected_host_status` and `daemon_status` for live read-only readiness checks.
+- `connected_host` and `daemon` for compact connected-host posture and direct `modelRoute` hints; use `includeParameters:true` for route families, allowed capabilities, blocked lifecycle/non-Agent surfaces, and first-class tool availability.
+- `connected_host_capability` for one allowed or blocked capability with the matching route hint.
+- `connected_host_status` and `daemon_status` for live read-only readiness checks and the next diagnostic route.
 - `operator_methods` and `operator_method` for the public method catalog.
 
 None of those modes expose host start, stop, restart, install, expose-listener, account creation, arbitrary route mutation, default knowledge access, hidden background Agent jobs, or implicit delegated review.
@@ -141,9 +150,17 @@ goodvibes-agent knowledge connectors
 goodvibes-agent knowledge connector <connector-id>
 goodvibes-agent knowledge connector-doctor <connector-id>
 goodvibes-agent knowledge ingest-url <url> --yes
+goodvibes-agent knowledge ingest-file <path> --yes
+goodvibes-agent knowledge ingest-connector <connector-id> --yes
 goodvibes-agent knowledge import-urls <path> --yes
 goodvibes-agent knowledge import-bookmarks <path> --yes
+goodvibes-agent knowledge import-browser-history --yes
 goodvibes-agent knowledge reindex --yes
+/knowledge queue
+/knowledge review-issue <issue-id> resolve --yes
+/knowledge packet <task>
+/knowledge explain <task>
+/knowledge consolidate light --yes
 ```
 
 Agent rejects route-selection flags that would target another knowledge space, including `--space`, `--knowledge-space`, `--knowledge-space-id`, and `--include-all-spaces`. Contaminated connected-host responses return `scope_contamination`.
@@ -165,7 +182,7 @@ Read views are safe by default. Mutations require exact target ids and confirmat
 /schedule run <schedule-id> --yes
 ```
 
-Routine promotion is an explicit scheduling bridge. Local routines stay local until a user confirms promotion. Delivery targets are opt-in with explicit channel/route/webhook/link flags.
+Routine promotion is an explicit scheduling route. Local routines stay local until a user confirms promotion. Delivery targets are opt-in with explicit channel/route/webhook/link flags.
 
 ## Slash Command Catalog
 
@@ -185,7 +202,7 @@ Routine promotion is an explicit scheduling bridge. Local routines stay local un
 | `/collapse` | Collapse rendered blocks by type. |
 | `/commands` | Browse all commands in a scrollable list. |
 | `/compact` | Summarize the conversation to free context window. |
-| `/compat` | Inspect Agent SDK pin, connected-host version, and Agent Knowledge route readiness. |
+| `/compat` | Inspect connected-host compatibility and Agent Knowledge route readiness. |
 | `/config` | Open the fullscreen configuration workspace. |
 | `/context` | Inspect context-window usage and token breakdown. |
 | `/conversation` | Review conversation structure, transcript hotspots, and composer posture. |

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

@@ -20,7 +20,7 @@ GoodVibes Agent supports spoken turns as an Agent TUI feature. Text output remai
 
 `/config tts` opens the fullscreen configuration workspace for streaming provider, voice, and spoken-turn model routing.
 
-The model can inspect the same settings through `agent_harness` settings modes, open the visible TTS provider or voice picker through `open_ui_surface`, and change Agent-owned TTS settings with explicit confirmation. `media_posture` is compact by default; use `includeParameters:true` or `media_provider` for full provider readiness, generation route hints, picker routes, and media policy detail. Connected-host listener or lifecycle settings remain outside Agent ownership.
+The model can inspect the same settings through `agent_harness mode:"settings"` or `mode:"get_setting"`, open the visible TTS provider or voice picker through `mode:"open_ui_surface"`, and change Agent-owned TTS settings with explicit confirmation. `mode:"media_posture"` is compact by default; use `includeParameters:true` or `mode:"media_provider"` for full provider readiness, generation route hints, picker routes, and media policy detail. Workspace action discovery includes compact `modelRoute` hints for TTS prompts, image input, and confirmed media generation; generated image/video requests use `agent_media_generate` when the user asks for that effect. Connected-host listener or lifecycle settings remain outside Agent ownership.
 
 ## Playback Requirements
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pellux/goodvibes-agent",
-  "version": "1.0.34",
+  "version": "1.0.36",
   "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",