🦋 New version release

[brentrager]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@smooai/smooth@0.18.0

Minor Changes

• 17541b6: Big Smooth's own chat loop now hosts SEP extensions (pearl th-6d8606). The daemon loads pre-trusted extensions once at startup into a shared ExtensionHost; every chat turn registers their tools alongside the pearl/teammate tools (gated by the same AutoMode permission hook and a newly-added Narc surveillance hook on the chat registry), routes their ui/* requests onto the existing UiRelay machinery in-process (task_id big-smooth-chat — no HTTP-to-self), and intercepts /cmd args chat messages as extension slash commands. New routes: GET /api/ext (loaded extensions + commands) and POST /api/ext/reload; th ext reload now hot-reloads the running daemon's host best-effort instead of always deferring to the next session.

• 4f51437: SEP Phase 3 (smooth) — th ext + the extension host substrate.

  th ext manages SEP extensions: install ./path [--project] [--trust] copies a local extension directory into ~/.smooth/extensions (or <repo>/.smooth/extensions), prints its declared capabilities, and prompts to trust it; list shows installed extensions with their trust state; trust <name> records trust; remove <name> deletes it. Trust is content-hashed and fail-safe — an extension only loads when it's recorded trusted in ~/.smooth/extensions/trust.toml and its extension.toml still hashes to the value trust was granted against (editing re-locks it), and a non-interactive install never trusts silently.

  smooth_code::sep_host is the frontend host substrate: a RenderBlock model for set_widget payloads (markdown/keyvalue/progress + text fallback), the UiSink trait that decouples ui/request from the ratatui event loop, TuiUiProvider (the engine HostDelegate that routes select/confirm/input/notify/set_status/set_widget/set_title onto a UiSink), the trust store, and load_trusted_host (discover → trust-gate → ExtensionHost::load declaring the seven TUI ui capabilities).

  Engine pin flipped from crates.io 0.14.0 to a git rev of smooai-smooth-operator-core main (SEP Phases 0–3, incl. the ui_capabilities handshake), which is not yet in a crates.io release. Flip back to a version pin once a release publishes the extension module.

  The live agent runs in smooth-operative; relaying a dispatched operative's ui/request to the TUI is SEP Phase 6 (the daemon event surface). This ships the CLI, trust model, and tested render/host substrate it builds on.

• 0449b2c: SEP Phase 4 (smooth) — attach extensions to the operative + th ext reload.

  Operative attach (pearl th-70cd08). The dispatched worker (smooth-operative)
  now discovers installed SEP extensions and loads the PRE-trusted ones into a
  headless ExtensionHost attached to its Agent, so their tools, tool_call
  hooks, and turn events run in real dispatched tasks and flow out on the existing
  AgentEvent stdout stream. Trust is fail-safe: unattended, an unknown or
  content-changed extension is silently skipped (never prompts). The delegate is
  the engine's headless default (empty ui_capabilities, -32001 NoUI for two-way
  ui/request until the daemon relay, Phase 6); extension tools ride the ordinary
  ToolRegistry, so the NarcHook surveillance already installed applies to them.

  Trust store extraction. TrustStore / TrustRecord / hash_extension /
  trust_path moved from smooth-code::sep_host down into smooth-policy
  (ext_trust) — a leaf crate both the TUI and the operative can depend on — and
  are re-exported from sep_host so the th ext CLI is unchanged.

  Engine pin. Bumped smooth-operator-core to the SEP Phase 4 engine rev
  (command dispatch, session actions, hot reload).

  th ext reload <name>. Re-validate an installed extension after editing it:
  re-parse the manifest, re-hash it, and (when the manifest changed) re-confirm
  trust so the next host start picks up the new version. In-session live reload
  (the engine's ExtensionHost::reload) lands with the daemon relay (Phase 6).

• 83094a4: SEP Phase 5 (smooth) — packaging, skills unification, marketplace search, legacy deletion.

  th ext install gains npm/git sources. Beyond a local directory, install from npm:@scope/pkg[@version] or git:host/user/repo[@ref]. npm packages are vendored under ~/.smooth/extensions/.npm (an npm install --prefix tree so their deps resolve), git repos under ~/.smooth/extensions/.git/<host>/<path> at the pinned ref (and npm installed when they carry a package.json). A ~/.smooth/extensions/<name> symlink to the vendored dir is what the engine discovers, so packaged and local installs load identically through the engine's existing top-level discovery. A manifest may be extension.toml or a smooth key in package.json (synthesized into extension.toml at install). Trust records the source spec so th ext update [<name>] re-fetches and reconciles — an unchanged manifest keeps its trust, a changed one is re-locked (fail-safe).

  th ext search <query> matches a curated index shipped in the binary plus live npm packages tagged with the smooth-extension keyword, printing the install command for each hit.

  Skills unification. A trusted extension's [resources] skills directory now feeds the one canonical skill catalog (smooth-cast) via skills::resources_discover; each SKILL becomes a /skill:<name> with source extension, gated on the same content-hashed trust (an untrusted extension contributes no skills — the skill body is a prompt-injection surface). The duplicate skill parser in smooth-code (extensions.rs) is deleted; /skill and the new /ext TUI command both read from smooth-cast. SkillSource gains an Extension variant and a shared label() (replacing five inline match copies).

  /ext TUI command lists installed extensions with their trust state and declared capabilities. Live command/UI dispatch into a running host reaches the TUI over the daemon event surface (SEP Phase 6).

  Deletions (migration verdicts). The zero-consumer smooth-plugin trait crate is removed (in-process trait plugins are exactly what SEP rejects), and the duplicate smooth-code skill parser is removed in favor of smooth-cast.

• 479035e: SEP Phase 6 (smooth side) — relay a dispatched operative's extension ui/*
  requests to smooth-web.

  A dispatched operative runs headless, so its new HttpUiProvider relays each
  ui/* request to Big Smooth over the existing SMOOTH_NARC_URL +
  SMOOTH_HOST_TOKEN callback channel (POST /api/ui/request — the same channel
  host_tool uses). Big Smooth broadcasts a UiRequest server event to connected
  frontends and, for the interactive kinds (select/confirm/input), blocks the
  operative's call until a browser answers via POST /api/ui/answer. The new
  smooth-web UiRelay component renders select/confirm/input as a modal,
  notify as a toast, and set_status/set_widget/set_title in the chrome;
  render blocks (markdown/keyvalue/progress/table/diff/stack, each with
  a text fallback) render natively.

  Unattended (no client connected) an interactive request resolves to
  {cancelled:true} rather than hang; under SMOOTH_AUTO_MODE=bypass a confirm
  is auto-answered {confirmed:true} (audited); otherwise it waits up to
  SMOOTH_UI_TIMEOUT_SECS (default 120s) then cancels.

  Also removes the dangling smooth-plugin workspace dependency entry (the crate
  was deleted in Phase 5).

• 5e6418a: SEP Phase 8 (smooth) — render-block v2 DSL parity in both frontends.

  Web (UiRelay.tsx). The daemon ui/* relay's RenderBlock now renders the
  Phase 8 interactive widget kind (its body block plus a legend of the declared
  keybindings) and aligns the table/diff/stack field names to the formalized
  DSL (columns/patch/children), accepting the pre-Phase-8 aliases
  (headers/diff/items) as a fallback.

  TUI (smooth_code::sep_host::RenderBlock). The terminal render-block
  substrate gains reduced-fidelity table (aligned columns), diff, stack
  (recursive), and widget (body + keybinding legend) kinds, matching the web and
  the SDK DSL, so a widget-driven extension degrades cleanly to the terminal.

  Deferred (out of Phase 8 scope, follow-ups filed). Live interactive
  widget/key routing from the TUI needs the engine-pin cutover to the Phase 8
  smooth-operator-core (which adds dispatch_widget_key) plus a live UiSink
  wired through the daemon relay (the daemon/auto-mode epic). Discovered
  [resources] themes application is deferred too: it needs either the compile-time
  theme.rs palette refactored to a runtime state (TUI) or theme colors plumbed
  through the daemon to the web SPA — discovery without either is dead code.

• 5b4d7a6: SEP Phase 7 (smooth) — th cast models surfaces extension-registered providers.

  th cast models now folds in LLM providers contributed by globally installed
  extensions (~/.smooth/extensions/). Any extension that registers a provider via
  the SEP registerProvider surface is loaded headlessly and its declared models
  are listed under an extension <ext>.<provider> section (in --json, as
  <provider>/<model> ids). Model ids are filtered + sorted like gateway/local
  models; a provider left with no matching models is dropped. Loading is gated to
  global extensions — a plain th cast models in a repo never spawns a project
  extension — and any failure yields an empty list, so extension providers are
  strictly additive and can't break the core listing.

  Engine pin bumped to the smooai-smooth-operator-core git rev carrying SEP
  Phase 7 (registerProvider / OAuth / proxied streaming / session/set_model),
  which exposes ExtensionHost::providers().

• 66b4cb0: SMOODEV-2259 — th api agents mint/update --extension carries per-agent extensionConfig (SEP extension enablement), mirroring --tool-config.

Patch Changes

• 994ed34: th api copilot — CLI bridge to the org's always-on dashboard Copilot (smooai PR #2383, pearl th-f15107).

  Three subcommands mirror the org-authed copilot routes on api.smoo.ai:

  • th api copilot chat "<message>" [--conversation <id>] [--json] — runs a turn, prints the reply plus a compact ran <tool> line per tool call. Continues an existing conversation with --conversation.
  • th api copilot confirm <conversation-id> --approve|--decline — resolves the destructive action a turn paused on, without resending the message.
  • th api copilot history <conversation-id> — prints the conversation's message history.

  Destructive tools (e.g. email.send) never auto-run: a turn that triggers one returns a pendingAction and pauses. chat resolves it with a y/N prompt on a TTY, or the up-front --confirm / --no-confirm flag for non-interactive/agent use. With no flag on a non-TTY it prints the pending action and stops rather than guessing — --no-confirm is never a silent default. Authenticates as the logged-in user (th auth login), like th api crm, so every tool run is audit-logged against the real person.

  Ships an org-copilot marketplace skill (claude-plugins/smooth-agent) teaching Claude Code when and how to drive the copilot (including the confirm-flow safety rules), and documents the surface in docs/Engineering/Using-th-CLI.md.