@sigrun/sigrun 0.0.0-stage → 0.1.0

package/CHANGELOG.md

@@ -0,0 +1,204 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [0.1.0] - 2026-10-21
+### Added (server)
+- Conversation list fields: name, last-activity, parent (fork lineage),
+  archived and pinned on the list payload — the per-conversation meta
+  N+1 is gone; fork trees sort by newest activity anywhere in the tree.
+- Automatic conversation naming: a one-shot naming call driven by the
+  `namingModel` setting (a model id, or `false` to disable; defaults to
+  the server default model with thinking off). Forks of named
+  conversations inherit `"<name> (fork)"`.
+
+### Added (tui)
+- Fullscreen alt-screen UI with mouse support: per-keymap themes,
+  status bar, and a turn-grouped transcript with foldable turns.
+- Action layer with configurable keymaps (standard / vim / emacs):
+  turn-aware search, prompt-jump and picker actions replace the
+  alt-screen built-ins; vim mode has real insert / normal / command
+  modes with `v` opening the prompt in vim.
+- Key reference overlay (`?` in standard/emacs, `g?` in vim).
+
+### Added (webui)
+- Theme system: palette / accent / mode, applied across the rail,
+  header and right-panel shell; visual design adapted from hermes-webui
+  by nesquena and contributors (credited in THIRD_PARTY_NOTICES).
+- Sidebar: named, grouped, searchable conversation list with pin and
+  archive.
+- Transcript: turn-grouped rendering with an activity line per turn
+  ("Thinking · 2 tools"), markdown everywhere, filterable tables
+  (filter bar above > 6 data rows), copy buttons on code blocks, a
+  transcript outline, and a scroll fade.
+- Composer model and thinking pickers.
+
+- Thinking blocks: `thinking` content blocks render as collapsible
+  `<details>` before each assistant message's text — expanded + pulsing
+  while the generation streams (`pi.live.generation.message` partials
+  render as a provisional entry), collapsed at rest, hidden entirely by
+  the new Interface setting.
+- A "working…" indicator (three pulsing dots) driven by `steer.busy`,
+  reading "compacting…" while a compaction task is live, plus a persistent
+  compaction-failure alert from `pi.live.compactionFailure`.
+- Submit chords: Ctrl+Enter / Cmd+Enter submit; the Interface setting's
+  "enter sends the prompt" adds plain-Enter submit (Shift+Enter stays a
+  newline).
+- Settings sections: the panel gains a left nav (General / Tools /
+  Interface / Advanced). Interface holds the new client-only prefs
+  (`enterToSend`, `showThinking`) — localStorage-backed (`sigrun.prefs`),
+  applied live, never sent to the server.
+- Workspace drawer: below 1000px the workspace panel opens as a right-side
+  overlay drawer (top-bar toggle, backdrop click / in-panel ✕ to close)
+  instead of being hidden.
+
+### Changed (webui)
+- Tool-call-only assistant messages render nothing — the empty bubble
+  above a tool card is gone.
+- The Compact button is removed (compaction is automatic server-side;
+  `/compact` remains a slash command). Composer controls sit in one row
+  (Attach · usage ring · Send) and the textarea matches their height.
+- The settings gear is larger; the top bar wraps badges instead of
+  overflowing horizontally at narrow widths.
+
+### Fixed (webui)
+- The Tools section's checkboxes collapsed into a vertical column with the
+  explanatory note clipped off the right edge (a `flex-direction` leak from
+  the `.settings-field` base), forcing a horizontal scrollbar.
+- `pi.live` doc narrowing gained the `generation`/`compactions`/
+  `compactionFailure` shapes the new consumers read.
+- Unified `extensions` list (install-and-load): one settings.json array
+  covers npm specifiers, `file:`/path checkouts, and git sources
+  (`git:host/path[@ref]` cloned into `<config-dir>/git/` with fetch/reconcile
+  + entry discovery: sigrun manifest > pi-compat manifest > dist/index.js >
+  index.ts). `{enabled: false}` = present-but-not-loaded. The separate
+  `packages` list is gone; `SIGRUN_EXTENSIONS` accepts the same grammar
+  per CSV chunk (JSON-object entries included).
+### Added
+- pi-style extension packages: the settings file's top-level `packages`
+  array (file-only — no `SIGRUN_PACKAGES`) declares npm specifiers boot
+  installs into `<config-dir>/packages/` (a real npm root: synthetic
+  private `package.json` + `node_modules/`, pi's `~/.pi/agent/npm` shape),
+  pruning undeclared entries, with a no-subprocess fast path when the dir
+  already matches. The loader resolves each `extensions` name against the
+  packages dir FIRST (deployment-installed wins), then bare import
+  resolution (paths, `file://` URLs, dev checkouts, image-bundled
+  packages). Install failure/timeout (120s) fails the boot naming the
+  specifier. Deployments declare extensions in `settings.json` and
+  restart — no image rebuild. Compose mounts the config dir on the data
+  volume (`SIGRUN_CONFIG_DIR=/data/config`); the chart defaults
+  `SIGRUN_CONFIG_DIR=/data/config` onto the same PVC as the database.
+- `server.webui` settings section (the webui channel surface):
+  `enabled` (default `true`; `false` is a positively API-only deploy —
+  nothing mounts even when a bundle is present) and `bundle` (the
+  selector — a value matching `^[a-z][a-z0-9_-]*$` is a contributed-bundle
+  NAME, a path-shaped value is a directory). `SIGRUN_WEBUI` is the strict
+  env gate (`true`/`false`, anything else fails loud);
+  `SIGRUN_WEBUI_BUNDLE` remains the env selector form.
+  `PATCH {server:{webui:{…}}}` sub-merges per key (a partial update no
+  longer drops a previously set `bundle`); a defaulted first boot
+  persists no webui keys at all.
+- Extension-contributed webui bundles: a factory result may carry
+  `webuiBundles: [{name, dir}]` (contract in `docs/extending.md`) — `dir`
+  resolves against the extension entry file's directory (the bundle lives
+  in the extension's package, never the server cwd), the server owns the
+  `index.html` check at serve time (a missing index is a boot error naming
+  the extension), and name collisions are last-registered-wins with a
+  warn. Selection by name via `server.webui.bundle`; the selected
+  bundle mounts exactly like the built-in one and
+  `capabilities.channels` reports its name (`"webui"` for the built-in
+  default).
+- `/v1/meta` gains a `collisions` field (`webui` + `providers`):
+  boot-merge collision records surfaced for operator visibility — the
+  provider collision sink was retained since the provider plan but never
+  readable until now.
+
+### Deprecated
+- `server.webuiBundle` — the legacy flat key reads as a deprecated alias
+  for `server.webui.bundle` for one release (accepted with a deprecation
+  warn). Selector precedence: `SIGRUN_WEBUI_BUNDLE` >
+  `server.webui.bundle` > legacy `server.webuiBundle` > the built-in
+  default. Bootstrap never writes the legacy key; migrate to
+  `server.webui.bundle`.
+
+### Changed
+- `charts/sigrun` is rewritten as a bjw-s common library (app-template
+  5.2.1) wrapper: the hand-written Deployment/Service/PVC/CronJob/
+  ServiceMonitor templates are replaced by
+  `templates/common.yaml` (loader init + generate) over a 5.2.1-schema
+  values.yaml (`controllers`/`service`/`persistence`/`serviceMonitor`).
+  The PrometheusRule stays a small hand template (the library has no
+  PrometheusRule class), gated independently on
+  `monitoring.prometheusRule.enabled`. The backup CronJob and the
+  ServiceMonitor are now opt-in defaults (public portable shape); the
+  Deployment's Recreate strategy, /healthz + /readyz probes, sigrun-env
+  envFrom secret, and the RWO sigrun-data PVC at /data are unchanged
+  contracts. test/manifests.test.ts asserts against the new render.
+- **BREAKING** (packaging): `@sigrun/tui` is a spawned package, not an
+  in-process import — `sigrun run`/`attach` spawn the `sigrun-tui` bin
+  (`tui/dist/launch.js`) as a child process; the agent-dies-with-the-TUI
+  lifecycle is preserved by the parent watching the child's exit. The
+  tui declares its own runtime deps (`@earendil-works/pi-tui` plus the
+  new `@sigrun/shared` leaf package carrying the theme tokens and shared
+  primitives) and core lists it as an optional dependency: `serve` needs
+  no tui, and a missing tui degrades `run`/`attach` with an actionable
+  "install @sigrun/tui" message instead of a module-not-found crash.
+- The CLI is buildable and installable: `npm run build` compiles
+  `@sigrun/shared` + `src` → `dist` (sourcemaps off; the `sigrun` bin is
+  `dist/cli.js` under plain node — the tsx shebang is gone); `tsx` moves
+  to devDependencies (dev `start`/`tui` scripts keep it); `prepublishOnly`
+  builds core + webui. Deploy entries run the built form — the Dockerfile
+  build stage gains `npm run build` with `CMD ["node", "dist/index.js"]`,
+  the chart's container command and backup CronJob are
+  `node dist/index.js` / `node /app/dist/backup/run-backup.js`, and
+  docker-compose runs `node dist/index.js` (no tsx in any deploy path).
+- The default webui bundle anchors to the package root instead of the
+  process cwd — an installed `sigrun serve` finds the bundle it ships
+  from any working directory; explicit path selectors keep cwd-relative
+  semantics, and an absent default stays the supported API-only deploy.
+
+### Removed
+- **BREAKING**: the extension-loader `.ts`-entry fallback. Extension
+  sources (`git:` and path checkouts) must ship a built `dist/index.js` —
+  a `.ts` entry no longer loads — it resolves only to quarantine at load
+  with a clear "build the package and ship its built entry
+  (dist/index.js)" error instead of riding the dev tree's tsx loader
+  (whose behavior under plain node depends on the host's
+  type-stripping flags). npm packages were never affected.
+
+### Changed (packaging)
+- Published as `@sigrun/sigrun` (CLI command stays `sigrun`) with
+  `@sigrun/shared` and `@sigrun/tui` as workspace-published companions —
+  exact intra-family pins (`0.1.0`), `publishConfig` access/provenance,
+  `repository.directory` for the workspace packages, and a manifest
+  hygiene suite (`test/package-manifest.test.ts`) pinning the published
+  shape. `webui` stays a private build input (its bundle ships inside
+  core's tarball as `webui/dist`).
+- The npm tarball is the runnable package only: `files` narrows to
+  `dist`, `webui/dist`, and the docs files — deploy assets (`scripts/`,
+  `docker/`, `charts/`, `Dockerfile`) live in the GitHub repo.
+- The three built-in extensions (`codemode`, MCP, tool search) ship as
+  core dependencies under their published names `@sigrun/ext-codemode`,
+  `@sigrun/ext-mcp`, `@sigrun/ext-tool-search` — the working tree keeps
+  `file:` dev links until the family publishes (Task 8).
+- The extension contract surface is `@sigrun/sigrun/extension`
+  (types-only subpath; every import, doc, and the consumer fixture
+  re-keyed).
+- The deprecated `createMemory` named-export loader bridge is DELETED
+  (release-0.1): packages must export the factory as default —
+  `@sigrun/memory-markdown` 0.1.0 does. The named `extension`
+  export bridge remains deprecated (loads with one warning).
+
+### Added
+- Durable personal assistant on pi-durable 1.2.0: the Harness (durable sessions,
+  tasks, compaction, settings store), the §5 server + webui, the skills/search
+  tool surface, extension loader (quarantine-on-failure), deploy manifests
+  (base + homelab overlay), and the pi-parity feature set (approvals, memory
+  surface, settings panel, command surface).
+- pi-durable upgraded 1.0.2 → 1.2.0: ToolExecutionResult `output` rename across
+  core, registry-driven settings roster, `modelTools` two-layer filtering.

package/CONTEXT.md

@@ -0,0 +1,163 @@
+# Context: why sigrun exists
+
+> Companion to the sigrun specs in `docs/superpowers/specs/` (the *what*):
+> `2026-10-04-sigrun-core.md` (core, zero external dependencies),
+> `2026-10-04-sigrun-hermes-replacement.md` (parity extensions + cutover),
+> `2026-10-04-sigrun-improvements.md` (post-hermes capabilities). The original
+> `2026-10-02-sigrun.md` is superseded and retained as decision history (the numbered
+> decision record, App B 1–23, lives there; its deployment §6 was carried into the core
+> spec, so the three active specs stand alone).
+> This document is the *why* — what the assistant is for, what it replaces, and
+> the constraints that shaped it. Written 2026-10-02.
+
+---
+
+## 1. What sigrun replaces, and why
+
+The user has run `hermes-agent` (in-cluster, via the `hermes-pantheon`
+chart) plus `hermes-webui` as a personal assistant. The assistant is genuinely
+useful — the memory system especially — but the software has become a bad fit:
+
+- **It is heavy.** The local config is ~800 lines. After the 2026-09-25
+  gateway-only cleanup, the overwhelming majority of it is dead: bedrock
+  discovery, docker sandbox variants, personalities, Mixture-of-Agents presets,
+  per-provider fallback plumbing, image-generation providers. The features that
+  actually get used are a handful of tools, cron, memory, and the webui.
+- **The webui runs a second agent loop.** hermes-webui imports the hermes code
+  and re-implements the agent loop independently of the primary CLI agent. Two
+  loops, two state paths, one codebase that has to keep them in sync.
+- **The workspace went away.** When hermes ran locally in the same WSL instance
+  as pi and opencode, everything shared a filesystem, and code written by pi was
+  immediately visible to hermes. Moving hermes into the cluster bought
+  always-on availability and lost that adjacency.
+- **It is not a good coding agent.** Attempts to use it as one produced poor
+  results. Coding stays in pi.
+
+Sigrun keeps the parts that earn their place (memory, scheduled jobs,
+agentic maintenance tools, web research, the webui as the primary surface)
+and discards the rest by construction.
+
+---
+
+## 2. What the assistant is actually for
+
+Stated by the user, in their words:
+
+- **Research.** The most common use. "Go find out about X." Which naturally
+  escalates:
+- **Research that turns into work.** If finding out about X reveals a tool to
+  build or software to update, the assistant should open a ticket in Forgejo and
+  hand the actual work to pi — not attempt the coding itself.
+- **Steering coding work from away from the desk.** Not doing the work, but
+  being able to answer a pi session's questions or prompt it to continue while
+  on a phone or laptop. Heavy lifting stays in pi inside herdr.
+- **Routine maintenance.** Existing cron jobs performing household and
+  self-hosted-service maintenance. The user wants *more* of this and keeps
+  not getting to it — calendar access, household context, and similar
+  assistant-ish chores.
+- **Ambient awareness.** Ingesting data sources such as Discord logs so the user
+  can catch up on what they missed, gauge community impressions of new models,
+  and track events. Read-only to start.
+- **Memory.** Honcho is described as "incredibly valuable." Parity with the
+  current honcho behavior is a v1 requirement, not an enhancement.
+- **Household multi-user, eventually.** "An agent that can assist my entire
+  household has clear value," with guardrails around data sharing. Authelia is
+  already the IdP, so this is an SP problem, not an identity problem.
+
+---
+
+## 3. Constraints that shaped the design
+
+### 3.1 The workspace problem
+
+The single most concrete complaint. A shared workspace between agents was
+valuable and the cluster migration broke it. But running a whole-home assistant
+from a personal workstation is not a good answer either — the workstation sleeps,
+and the assistant should not.
+
+Resolution: the assistant's *core* lives in-cluster (always on, durable), and the
+*workspace* is resolved rather than fixed. Day one uses a static workspace
+configuration; the swap to dynamic resolution is a wrapper change, not a
+rewrite. The interaction surfaces (webui now, TUI and
+audio later) attach to the in-cluster core from anywhere over the tailnet.
+
+Precedent the user liked and lost: `opencode serve` on the workstation with
+`opencode attach` from any of three machines, working over the tailnet. That
+serve/attach model is exactly what a durable harness gives back — one long-lived
+process owning state, thin clients attaching.
+
+### 3.2 pi-durable is the substrate
+
+Chosen because it is the only option that makes the "second agent loop" problem
+structurally impossible: the loop lives in the harness, and every surface
+(webui, TUI, cron trigger, future channels) is a client submitting to and
+watching conversations. It also brings crash survival and idempotent
+submissions (requestId dedup — exactly-once-across-crash semantics are
+pending M1 verification), which the current stack lacks.
+
+Known constraints accepted at choice time:
+
+- Experimental; the API changes between releases (`1.0.2` at spec time;
+  pinned exactly, with a captured-schema drift fixture and an upgrade drill
+  in the core spec).
+- One process owns a storage file at a time; no cross-process locking. Matches
+  the single-harness design anyway.
+
+Resolved since the choice (2026-10-04 probes against the pinned package):
+image input **works** (base64 inline in submissions — verified live), and the
+async-approval mechanism works across crash+restart (`beforeTool` + durable
+memo — verified live). These were open questions at choice time; they are now
+verified facts recorded in the core spec's Appendix C.
+
+### 3.3 Keep pi's philosophy
+
+The user's stated preference: **minimal core, well-defined interfaces for
+extensibility, and an ecosystem.** Their pi install is the proof it works — 19
+packages, each doing one thing, composed into a workflow.
+
+So sigrun is: a small harness, a webui, and a set of extensions that are
+individually replaceable. Not a platform.
+
+### 3.4 The webui is the primary surface
+
+Called out twice in the design conversation. The plan is to take hermes-webui's
+UX shamelessly (three-panel layout, composer footer, tool cards, context ring)
+while replacing everything beneath it with thin client calls to the harness API
+— which is why the stack decision in the spec is *port the frontend, gated on a
+60% reuse measurement*, with a rebuild as the documented fallback.
+
+### 3.5 Cross-agent tools belong in the fabric, not the agent
+
+Hard-won: the assistant needs a work ledger that spans repositories and
+outlives any particular agent. If the kanban is a hermes plugin, moving to a
+different assistant means re-doing the integration. So cards live in the
+fabric's card system (skuld), and sigrun is just a client — as pi will be, as
+anything else will be.
+
+---
+
+## 4. What sigrun deliberately does not do
+
+- **Coding.** pi + herdr own that. Sigrun creates the ticket and the card.
+- **Provider management.** Bifrost already routes models with virtual keys,
+  budgets, and failover chains. Sigrun points at one VK.
+- **Multi-user UI in v1.** The `owner` field exists; the auth flow does not.
+- **Write-side Discord, voice, generalized object memory.** Deferred, each with
+  a documented seam so it can be added without redesign.
+
+---
+
+## 5. Names
+
+**sigrun** — a Norse valkyrie; a messenger/attendant figure. Chosen over:
+
+- **iris** — reads as the lesser-known female counterpart to hermes; the user
+  disliked the implicit gender-flip construction.
+- **argus** — the watcher; also the guy hermes slew, which is an odd name for
+  hermes's replacement.
+- Various scribe/messenger deities (thoth, seshat, ogma, muninn) — all already
+  taken in the agent/AI space, several by direct competitors.
+- Norse fits: the bifrost gateway already lives in that mythology.
+
+**skuld** — held in reserve for the work-item side of the fabric ("that which
+shall become").

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Michael MacLeod
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.