@pellux/goodvibes-agent 1.4.4 → 1.5.1

package/CHANGELOG.md

@@ -2,6 +2,28 @@
 
 Product-facing release notes for GoodVibes Agent.
 
+## 1.5.1 - 2026-06-14
+
+- v1.5.1 is a patch on the 1.5 line. The fullscreen Agent workspace, Agent-local behavior, isolated Agent Knowledge, connected-host operator integration, and explicit side-effect boundaries all stay in force; this release restores the inline shell escape and refreshes release verification.
+- Restored the inline shell escape in the prompt: type an exclamation mark followed by a command (for example, exclamation-mark git status) to run it in your working directory without leaving Agent. The command output appears inline, and the result is carried into your next message as context so you can run something and immediately ask about it. The composer already showed this as shell mode, but the command never actually ran since the workspace fork; it executes again now.
+- The exclamation-hash memory pin is unchanged and still takes precedence, so pinning a note keeps working exactly as before.
+- Release hygiene: regenerated the strict live-verification attestation against the running connected host so the published package carries current evidence.
+- Test suite: 7931 pass / 0 fail / 2 skip across 554 files.
+
+## 1.5.0 - 2026-06-11
+
+- v1.5.0 opens the 1.5 minor line: the fullscreen Agent workspace remains the primary user surface, Agent-local behavior, isolated Agent Knowledge, connected-host operator integration, explicit side-effect boundaries, and release hardening from 1.3.x and 1.4.x all stay in force. This release replaces the split-pane panel system with the Activity sidebar, rebuilds first-run onboarding around readiness, and adds local calendar, direct email, hardware-aware model recommendations, and skill import/export.
+- Replaced the 21-panel split-pane system with a single Activity sidebar. Live activity, process output, and runtime state now surface in one consistent lane instead of stacked panels; the footer was slimmed and tool calls show human-readable labels.
+- Rewrote the workspace Home as plain-language lanes and merged duplicate categories. The slash-command long tail moved behind /commands so the prompt surface stays focused on what users actually run.
+- Added a While you were away digest on return plus a live Coming up sidebar fed by the local calendar, so upcoming commitments stay visible without asking.
+- Rebuilt first-run onboarding around a readiness model: setup steps sequence themselves by what is actually configured, the flow can be resumed midway, and a completion recap shows what was set up. The first screen leads with a working path, the first-run model picker opens with a hardware-fit recommendation, and a plain-language hint appears in conversation while setup is incomplete.
+- Competitive parity wave: local calendar support, direct email send and read over SMTP and IMAP with TLS or STARTTLS, hardware-aware model recommendations, and automatic skill drafts.
+- Skills now import and export in the open skill standard. Exports are lossless, and skills discovered from imports stay disabled until explicitly enabled.
+- Hardened the email and calendar surfaces: SMTP and IMAP commands validate addresses and reject control characters, STARTTLS upgrades verify no data arrives before negotiation completes, and calendar parsing is stricter about malformed input.
+- Reliability fixes across the TUI: closed a text-wrap hang, made wide-character rendering consistent, fixed webhook notifier reuse, routed the benchmark editor to its real action, and made command failures surface user-visible errors everywhere.
+- Release and verification hygiene: the operator token is redacted from release artifacts, the coverage ledger reports honest numbers, release evidence is checked for existence, and operator-facing copy passes a plain-language gate.
+- Test suite: 7931 pass / 0 fail / 2 skip across 554 files.
+
 ## 1.4.4 - 2026-06-09
 
 - v1.4.4 continues the stable 1.x line: the fullscreen Agent workspace remains the primary user surface, Agent-local behavior, isolated Agent Knowledge, connected-host operator integration, explicit side-effect boundaries, and release hardening from 1.3.x and 1.4.x all stay in force. This patch finishes the onboarding-modal cleanup begun in 1.4.0–1.4.3.

package/README.md

@@ -1,7 +1,7 @@
 # GoodVibes Agent
 
 [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](https://opensource.org/licenses/MIT)
-[![Status: 1.0.x](https://img.shields.io/badge/status-1.0.x-green.svg)](#install)
+[![Version: 1.5.0](https://img.shields.io/badge/version-1.5.1-blue.svg)](#install)
 
 GoodVibes Agent is the installable autonomous operator assistant for GoodVibes. It keeps the existing terminal renderer and workspace bones, but the product goal is different from a vibecoding harness: the user should experience one assistant that can chat, plan, remember, research, schedule, send, generate, run visible agents, and operate the GoodVibes daemon contract with clear confirmation gates.
 
@@ -69,13 +69,58 @@ Press `/` inside the workspace to search actions by name, category, command, or
 
 The main Agent model can inspect and operate the Agent-controlled harness through Agent-owned tools. The important first-run entrypoint is `setup`; the detailed catalog entrypoint is `agent_harness`.
 
-`route action:"plan" query:"..."` is the first stop when a plain user task could map to several GoodVibes surfaces. It returns the preferred visible route, alternatives, missing fields, confirmation boundary, workspace matches, and harness mode matches without running tools; host/daemon health or doctor wording routes to `host action:"status"`, normal settings/configuration wording routes to `settings action:"list"`, model provider/local-cookbook/smoke/route-fit wording routes to `models action:"provider|local|smoke|route"`, Personal Ops briefing/queue/fresh-read/connector wording routes to `personal_ops action:"briefing|queue|intake|lane"`, direct reminders/schedule lifecycle wording routes to `schedule action:"list"` and confirmed schedule actions, command-shaped background work routes to `execution action:"processes"` and the first-class `terminal`/`process` UX, interactive PTY/stdin/sudo wording routes to `execution action:"process_capabilities"` before any start or credential effect, external memory-provider/backend/sync/import/export wording routes to `memory action:"provider"` or the provider contract checklist, browser-backed research runner wording routes to `research action:"runner"`, visual research report rendering routes to `research action:"plan"` plus report artifacts, voice workflow and TTS-provider wording routes to `device action:"voice|provider"`, browser cockpit/PWA wording routes to `computer action:"browser"` before any visible open handoff, channel setup/triage/delivery-receipt/send wording routes to `channels action:"setup|triage|deliveries|channel"` before confirmed external delivery, security permission/status/finding/blocked-action wording routes to `security action:"status|finding|explain"` before policy changes or risky work, support-bundle wording routes to `support action:"status|bundle"` before bundle export/import/share effects, saved-session/bookmark/continuity wording routes to `sessions action:"list|get"` before session lifecycle effects, release readiness/evidence/audit wording routes to `audit action:"readiness|evidence|item|artifact"`, file undo/redo/recovery wording routes to `execution action:"recovery"`, media generation wording routes to provider readiness plus confirmed `agent_media_generate` artifacts, and screenshot, browser-navigation/control, screen-observation, and desktop-control wording routes to `computer action:"plan"` before any live UI tool is considered. `setup action:"repair"` is the first stop for setup or host fix requests; it chooses the safest next token repair, connected-host status, services.status receipt, user-run bootstrap, or no-action route without executing it. `agent_harness mode:"summary"` is compact by default. It returns counts, status, and a short mode guide. `mode:"modes"` searches every harness mode by task, family, effect type, id, alias, or parameter name; `mode:"mode"` inspects one mode contract, and `mode:"route_decision"` remains the lower-level compatibility route for the same user-task planner. Plural catalog modes are also compact by default: they return ids, labels, counts, safe state, effect class, and short route hints. Workspace, command, UI, panel, shortcut, and keybinding discovery should normally use `workspace action:"status|actions|action|run|surfaces|surface|open|commands|command|run_command|shortcuts|keybindings|keybinding"`, while lower-level harness modes remain for compatibility/detail inspection. Connected-host posture/status/capability and operator/audit rows include compact `modelRoute` or `modelAccess` hints so the model can choose the right first-class tool or confirmed harness route without expanding every row. Use `settings action:"list|get|set|reset|import"` for normal configuration work and `host action:"status|capabilities|capability|services|service|methods|method"` for normal connected-host/daemon diagnostics. Use `includeParameters:true` or a singular inspect mode when the model needs schemas, detailed route hints, full policy blocks, redacted log tail, operator/audit artifact data, or editor field definitions.
+### Route planning
+
+`route action:"plan" query:"..."` is the first stop when a plain user task could map to several GoodVibes surfaces. It returns the preferred visible route, alternatives, missing fields, confirmation boundary, workspace matches, and harness mode matches without running any tools.
+
+The planner maps task wording to a preferred route:
+
+| When the task sounds like… | Preferred route |
+| --- | --- |
+| Host/daemon health or doctor | `host action:"status"` |
+| Normal settings/configuration | `settings action:"list"` |
+| Model provider, local cookbook, smoke, or route-fit | `models action:"provider\|local\|smoke\|route"` |
+| Personal Ops briefing, queue, fresh-read, or connector | `personal_ops action:"briefing\|queue\|intake\|lane"` |
+| Direct reminders or schedule lifecycle | `schedule action:"list"` + confirmed schedule actions |
+| Command-shaped background work | `execution action:"processes"` + first-class `terminal`/`process` UX |
+| Interactive PTY/stdin/sudo | `execution action:"process_capabilities"` before any start or credential effect |
+| External memory provider, backend, sync, import, or export | `memory action:"provider"` or the provider contract checklist |
+| Browser-backed research runner | `research action:"runner"` |
+| Visual research report rendering | `research action:"plan"` + report artifacts |
+| Voice workflow or TTS provider | `device action:"voice\|provider"` |
+| Browser cockpit/PWA | `computer action:"browser"` before any visible open handoff |
+| Channel setup, triage, delivery receipt, or send | `channels action:"setup\|triage\|deliveries\|channel"` before confirmed external delivery |
+| Security permission, status, finding, or blocked action | `security action:"status\|finding\|explain"` before policy changes or risky work |
+| Support bundle | `support action:"status\|bundle"` before bundle export/import/share effects |
+| Saved session, bookmark, or continuity | `sessions action:"list\|get"` before session lifecycle effects |
+| Release readiness, evidence, or audit | `audit action:"readiness\|evidence\|item\|artifact"` |
+| File undo/redo/recovery | `execution action:"recovery"` |
+| Media generation | provider readiness + confirmed `agent_media_generate` artifacts |
+| Screenshot, browser navigation/control, screen observation, or desktop control | `computer action:"plan"` before any live UI tool is considered |
+
+`setup action:"repair"` is the first stop for setup or host fix requests. It chooses the safest next route — token repair, connected-host status, services.status receipt, user-run bootstrap, or no action — without executing it.
+
+### Inspecting the harness
+
+- `agent_harness mode:"summary"` — compact by default; returns counts, status, and a short mode guide.
+- `mode:"modes"` — searches every harness mode by task, family, effect type, id, alias, or parameter name.
+- `mode:"mode"` — inspects one mode contract.
+- `mode:"route_decision"` — lower-level compatibility route for the same user-task planner.
+- Plural catalog modes are compact by default: they return ids, labels, counts, safe state, effect class, and short route hints.
+
+For everyday discovery and diagnostics, prefer the first-class tools over raw harness modes:
+
+- Workspace, command, UI, shortcut, and keybinding discovery: `workspace action:"status|actions|action|run|surfaces|surface|open|commands|command|run_command|shortcuts|keybindings|keybinding"`.
+- Normal configuration: `settings action:"list|get|set|reset|import"`.
+- Connected-host/daemon diagnostics: `host action:"status|capabilities|capability|services|service|methods|method"`.
+
+Connected-host posture/status/capability and operator/audit rows include compact `modelRoute` or `modelAccess` hints, so the model can pick the right first-class tool or confirmed harness route without expanding every row. Pass `includeParameters:true` or use a singular inspect mode when you need schemas, detailed route hints, full policy blocks, a redacted log tail, operator/audit artifact data, or editor field definitions.
 
 High-value `agent_harness` mode groups:
 
-- Discovery: `modes` and `tools`; use `workspace action:"status|actions|commands|cli_commands|panels|surfaces|shortcuts|keybindings"` for workspace/UI/command/key discovery and `settings action:"list"` for settings.
-- Single-item inspection: `mode` and `tool`; use `workspace action:"action|command|cli_command|panel|surface|keybinding"` and `settings action:"get"` for one item.
-- User-visible effects: use `workspace action:"run|run_command|open_panel|open|run_keybinding|set_keybinding|reset_keybinding"`, `terminal command:"..." background:true`, `process action:"wait|kill|write"`, and `settings action:"set|reset|import"`; all visible/mutating routes remain confirmation-gated.
+- Discovery: `modes` and `tools`; use `workspace action:"status|actions|commands|cli_commands|surfaces|shortcuts|keybindings"` for workspace/UI/command/key discovery and `settings action:"list"` for settings.
+- Single-item inspection: `mode` and `tool`; use `workspace action:"action|command|cli_command|surface|keybinding"` and `settings action:"get"` for one item.
+- User-visible effects: use `workspace action:"run|run_command|open|run_keybinding|set_keybinding|reset_keybinding"`, `terminal command:"..." background:true`, `process action:"wait|kill|write"`, and `settings action:"set|reset|import"`; all visible/mutating routes remain confirmation-gated.
 - Product posture: `channels action:"status|channel|setup|triage|deliveries"`, `notifications`, `provider_accounts`, `mcp_servers`, `setup action:"status|repair"` or detailed `setup_posture`, `host action:"status|capabilities|services|methods"`, `context action:"status|files|file|prompt|receipts|receipt"`, `memory action:"status|provider|curator|candidate|list|search|get"`, `agent_orchestration`, `model_routing`, `execution action:"status|route|history|record|processes|process_capabilities|process|recovery"`, `computer action:"status|plan|control|browser|setup|mcp"`, `personal_ops action:"briefing|status|queue|intake|lane|read"`, `document_ops`, `pairing_posture`, `delegation action:"status|routes|route"`, `security action:"status|finding|explain"`, `support action:"status|bundle"`, `media_posture`, `sessions action:"list|get"`.
 - Local long-running commands: `execution action:"processes"` and `execution action:"process"` inspect tracked ProcessManager jobs with bounded redacted output; `execution action:"capabilities"` or `action:"process_capabilities"` reports the same read-only process parity matrix as `process action:"capabilities"` for terminal background start, process list/poll/wait/log/kill/write, PTY, and sudo without overclaiming unsupported interactive routes. Confirmed `terminal command:"..." background:true` starts one visible local process, and `process action:"poll|log|wait|kill|write"` manages it. Lower-level `background_processes`, `background_process`, and confirmed `run_background_process` remain compatibility routes. `setup action:"item" setupItemId:"sudo-execution-posture"` shows SUDO_PASSWORD presence only, blocked background sudo routes, and foreground-supervised escalation guidance without reading or printing raw password values.
 - Visible Agent orchestration: `agent_orchestration` lists the live Agent manager, serial-by-default policy, managed multi-agent plan cards with milestones, work-plan links, dispatch receipts, closeout review routes, remote-runner contracts/artifact trails, auto-attached remote artifact review routes, spawn/batch-spawn decision cards, and safe control routes; `agent_orchestration_agent` inspects one visible subagent with its plan card. Approved work-plan items dispatch through confirmed `agent_work_plan action:"dispatch_agents"` into first-class `agent` spawn or batch-spawn calls with saved receipts. Actual spawn, message, wait, and cancel actions stay on the first-class `agent` tool.
@@ -93,7 +138,7 @@ First-class model tools cover common workflows directly:
 - `memory action:"status|provider|curator|candidate|list|search|get"` for Agent-local memory posture, provider readiness, review queues, and memory records; external-memory providers expose provider-specific next routes, missing setup/status/read/write/sync checklist items, and required receipt fields before Agent claims Honcho, Mem0, Supermemory, or similar backends are connected. `agent_local_registry` and `agent_learning_consolidation` remain the detailed routes for notes, personas, skills, bundles, routines, and confirmed duplicate-consolidation phases. Use `memory action:"status"` first when the user asks what memory knows, whether recall is healthy, or whether an external memory provider is actually connected.
 - `channels` for channel readiness, setup guide, triage, and delivery receipts; `agent_channel_send` remains the confirmed send route.
 - `support`, `sessions`, and `audit` for read-only support-bundle routes, saved-session/bookmark posture, release readiness, and packaged release evidence without requiring harness mode names.
-- `workspace` for Agent workspace categories/actions, slash and CLI command discovery, visible UI/panel navigation, shortcuts, keybindings, and confirmed workspace/command/keybinding effects.
+- `workspace` for Agent workspace categories/actions, slash and CLI command discovery, visible UI navigation, shortcuts, keybindings, and confirmed workspace/command/keybinding effects.
 - `agent_work_plan` for visible local work-plan tracking and confirmed dispatch of approved plan items to visible agents.
 - `personal_ops` for daily briefing, request intake, lane inspection, and one confirmed read-only inbox/calendar connector operation.
 - `autonomy action:"intake|queue|item|status"` for ongoing-work route selection and visible autonomous-work queue inspection without requiring harness mode names.
@@ -160,7 +205,7 @@ Service lifecycle and listener changes are available only through explicit setup
 
 GoodVibes Agent owns the autonomous assistant harness: the terminal renderer, setup UX, chat, local behavior libraries, Agent Knowledge routes, companion chat, visible agents, work plans, schedules, approvals, channel/media/reminder tools, daemon method access, and user-facing autonomy status.
 
-GoodVibes TUI remains the vibecoding harness and is still useful when the user wants its coding panels or execution-isolation UX. Agent should use local tools, visible agents, daemon automation, delegation, or remote runners according to what best serves the user, not because package boundaries are exposed as product friction.
+GoodVibes TUI remains the vibecoding harness and is still useful when the user wants its execution-isolation UX. Agent should use local tools, visible agents, daemon automation, delegation, or remote runners according to what best serves the user, not because package boundaries are exposed as product friction.
 
 ## Package Docs