Skip to content

Releases: prof18/regesto

v0.8.1

Choose a tag to compare

@prof18 prof18 released this 18 Oct 16:18

regesto upgrade now refreshes an engine copied into your knowledge base. The
bin/regesto-* commands prefer <knowledge base>/bin/regesto over the engine on your PATH,
but outside a source checkout nothing ever updated that copy. After an upgrade to 0.8.0 it
could be an older engine that rejects the new profile field, so every bin/regesto-* command
failed with unknown field "previous_targets". Upgrade now replaces that copy with the
engine running the upgrade. It doesn't create one where there was none, and it leaves
symlinks and source checkouts alone.

The write skill now tells agents to drop --dir for global facts. The writer rejects
--dir on a global claim, and agents copying the example command kept hitting that error.

Run regesto upgrade after installing to pick up both.

v0.8.0

Choose a tag to compare

@prof18 prof18 released this 15 Oct 12:47

Upgrade every synced machine's engine before any of them runs regesto upgrade.
This version adds a field to the integration profiles in your knowledge base, and 0.7.1
refuses to load profiles it does not recognise. If a knowledge base syncs between machines,
install 0.8.0 on all of them first, then run regesto upgrade on one of them.

Codex, Copilot, OpenCode, and pi now share one copy of the skills. All four read the
shared ~/.agents/skills folder as well as their own, so each Regesto skill used to load
twice in them. Regesto now links the skills into ~/.agents/skills only. regesto upgrade
removes the links it left in ~/.codex/skills, ~/.copilot/skills,
~/.config/opencode/skills, and ~/.pi/agent/skills, and only links that point at this
knowledge base's own skill copies; anything else in those folders stays. Claude Code,
Antigravity, and Hermes keep their own skills folders. If you set skills_dir for one of
the four to avoid duplicates, you can drop that override now.

Every agent now gets the same skill text. Claude Code's search skill no longer runs the
search before it loads; it calls the search command with your actual query, like every
other agent. The old shortcut put Claude-only syntax into folders other agents read, and
invoking it without a query printed the whole index. The
OPENCODE_DISABLE_CLAUDE_CODE_SKILLS advice from 0.7.0 no longer applies: when OpenCode
sees a Regesto skill twice, both copies are identical.

After upgrading, start new sessions in your agents so they reload their skills.

v0.7.1

Choose a tag to compare

@prof18 prof18 released this 14 Oct 13:29

The OpenCode plugin now works with OpenCode 2. OpenCode 2 replaced its plugin API,
and plugins written for OpenCode 1 do not load there, so OpenCode 2 sessions started
without the knowledge-base context. The linked launcher now serves both generations from
one file: OpenCode 2 appends the index and the facts scoped to your repository to the
first message of each session, while OpenCode 1 (1.18.29 or newer) keeps the previous
behavior. Existing installs only need regesto upgrade after installing this version,
then a restart of OpenCode.

v0.7.0

Choose a tag to compare

@prof18 prof18 released this 13 Oct 21:20

New built-in integration: the Pi coding agent. pi auto-discovers an extension Regesto
links into ~/.pi/agent/extensions/, and that extension injects the knowledge-base index
and the facts scoped to the working directory as a persistent message on the first prompt
of every session — the same deterministic consultation Claude Code gets, with no settings
file edited. The integration also links the portable skills into ~/.pi/agent/skills and
creates ~/.pi/agent/AGENTS.md with the marked knowledge-base section. pi keeps no
markdown memory, so harvesting is unchanged. On machines where the shared
~/.agents/skills already carries Regesto skills, override skills_dir for pi so it does
not load two copies of the same names.

New built-in integration: OpenCode. OpenCode auto-discovers a plugin Regesto links
into ~/.config/opencode/plugins/, and that plugin injects the knowledge-base index and
the facts scoped to the current repository on the first message of every session — the
same deterministic consultation Claude Code gets, with no settings file edited. The
integration also links the portable skills into ~/.config/opencode/skills and creates
~/.config/opencode/AGENTS.md with the marked knowledge-base section. OpenCode keeps no
markdown memory, so harvesting is unchanged. On machines that also run the Claude
integration, set OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1 so OpenCode does not load the
duplicate Claude-variant skills from ~/.claude/skills.

v0.6.0

Choose a tag to compare

@prof18 prof18 released this 15 Sep 14:32

You can now import the memory your agents already have. Until now the first harvest
only noted existing memory as a starting point and collected what changed after it, so
anything written before Regesto never reached the knowledge base. Run
regesto harvest --backfill once to copy that memory into inbox/, or name agents to
limit it, for example regesto harvest --backfill claude. The notes wait in the inbox
until the next regesto cycle turns them into facts, so you can look through them first.
Running it again does not import the same files twice. Scheduled harvests never import on
their own.

regesto init now offers the import right after you pick your agents, showing how many
memory files each one has. Harvest reads Claude Code, Codex, and Hermes memory; Copilot and
Antigravity keep no memory files.

On a machine that was already harvesting, the import can include notes an earlier harvest
collected. The normalizer skips facts it already has, so expect a longer first cycle rather
than duplicate facts.

v0.5.0

Choose a tag to compare

@prof18 prof18 released this 15 Sep 13:07

Two new built-in integrations: GitHub Copilot CLI and Antigravity CLI. Both inject
relevant context through a hook at the start of a conversation, like Claude Code, and get
the search and write skills. The Copilot install also covers Copilot in VS Code, which
reads the same skills, instructions, and hooks. See
Copilot setup and Antigravity setup.

Choosing agents no longer means editing config.toml by hand. regesto init now
shows a checklist of the agents it detected, so you can pick which ones to connect. Pass
--integrations claude,codex to skip the checklist (for example in scripts). On an
existing knowledge base, regesto integrations add <id> and
regesto integrations remove <id> change the list and leave your comments in
config.toml alone. Run regesto integrations without ids to get the checklist. The
command only edits the config: run regesto install afterwards.

Output uses plain words. Help, errors, and reports say "knowledge base", "agents",
and "notes" instead of internal terms. init ends with a short summary and numbered next
steps. doctor starts with one merged "What to do" list. install and upgrade group
their changes by agent. Newly generated config.toml files have shorter comments that
say when a setting is worth changing. JSON and key=value output have not changed.

Inbox processing picks its default agent from what you connected. It uses Claude
Code (Sonnet, low effort) and Codex (Luna, high effort) when either is connected. If
neither is, it falls back to Copilot, Antigravity, or Hermes, preferring connected ones
over ones that are only installed. A normalize command you set yourself still wins, and it
can now take the prompt as a {prompt} argument, for CLIs that don't read it from stdin.

v0.4.2

Choose a tag to compare

@prof18 prof18 released this 08 Sep 07:54

The command-line output is easier to scan. The main help now groups commands by purpose,
and command help works without an existing instance. Install,
lint, normalize, schedule, and related reports now use clearer headings, spacing, and
summaries; healthy details are condensed unless they need attention.

regesto doctor now opens with a readable status summary and remediation steps. Use
regesto doctor --verbose when you need healthy artifacts and the full trust rules as
well. Machine-readable JSON and MCP output remain unchanged, so existing automation can
continue to consume the same reports.

v0.4.1

Choose a tag to compare

@prof18 prof18 released this 06 Sep 14:09

macOS release binaries are now Developer ID signed and notarized. Background jobs
installed with regesto schedule install can therefore be attributed to the identified
developer instead of appearing in System Settings as items from an unidentified developer.

Release preparation now runs on the signing Mac and stops with reviewable archives and
checksums before any publication. Publishing remains an explicit second command and then
starts the Homebrew tap's existing secret-free updater. Apple signing certificates and
notarization credentials are never copied into GitHub Actions. Linux binaries and the
installation commands are unchanged.

v0.4.0

Choose a tag to compare

@github-actions github-actions released this 04 Sep 19:01

Integrations are now capability-driven instead of hardcoded to Claude Code and
Codex.
A declarative profile describes detection, skills, instructions, hooks,
native-memory sources, and default trust. Built-in profiles cover Claude Code,
Codex, Hermes, and a generic local integration; additional local profiles can be
added without changing the engine. Configuration now uses integrations = [...] and
per-integration override sections; old single-user instances are updated manually rather
than carrying an automatic migration layer.

regesto install now plans and applies those profiles through the Go engine. Its
versioned JSON dry-run reports canonical targets, ownership, current and intended
state, backups, and the exact action before anything is written. Shared skill or
instruction targets are reconciled once, generated artifacts carry ownership
markers, hooks are registered through declared protocols, and symlink or path
escapes are refused.

Every integration gets portable Regesto skills. Claude keeps its tailored
variant while Codex, Hermes, and generic integrations receive the same search,
write, and promote workflows through stable instance shims. Instruction blocks
use bounded markers, preserve host-owned text, and can be installed into more than
one declared target without duplicating content.

Native Markdown memory can now be harvested from every declared source with a
separate persisted baseline. Overlapping declarations deduplicate publication,
untrusted sources remain quarantined, and all reads
and writes stay within descriptor-verified roots. No proprietary cloud-memory
connector or network transport was added.

A local stdio MCP server exposes Regesto resources and tools. regesto mcp
implements the 2025-06-18 initialize lifecycle, tools, resources, bounded JSON-RPC
framing, and clean EOF shutdown using the same validation and trust rules as the
CLI. It listens on no socket and writes only protocol messages to stdout.

regesto doctor [--integration ID] [--json] provides deterministic, read-only
diagnostics for detection, installed artifacts, capabilities, memory, and trust,
with concrete remediation. The documentation now includes a profile-derived
capability matrix and setup recipes for Claude Code, Codex, Hermes, generic local
tools, and MCP clients.

Cycle alert delivery is now explicit and portable. Regesto no longer posts built-in
desktop notifications through macOS osascript or Linux notify-send; the former opens
Script Editor when clicked and neither backend can offer one coherent CLI interaction.
External alerts are sent only when [notify].command names a user-chosen executable. The
existing argument and REGESTO_NOTIFY_* environment contract is unchanged. Independently
of that optional delivery, the current failure reason and age now appear at the top of
agent context, so an agent is warned before relying on stale generated indexes.

If you are upgrading an existing 0.3.x instance, configure [notify].command if you
want external alerts.
With no command, desktop alerts stop after the upgrade; see the
README alert configuration for the small
configuration block.

The release gate now builds the engine away from its knowledge-base instance and
drives init, inert install dry-run, install, doctor, lint, upgrade, and an MCP
handshake inside a disposable HOME.

v0.3.1

Choose a tag to compare

@github-actions github-actions released this 27 Aug 08:14

Scheduled cycles can now find normalisers installed outside macOS's system paths.
LaunchAgents do not read shell startup files and launchd gives them only
/usr/bin:/bin:/usr/sbin:/sbin by default. A normal terminal could therefore run
claude and codex while the hourly cycle could find neither—common on Apple Silicon,
where Homebrew installs them under /opt/homebrew/bin. Harvesting and linting kept
running, but raw captures stayed in the inbox instead of becoming facts.

regesto schedule install now gives both jobs a deterministic PATH. It includes the
directories of the configured normaliser and notifier commands found during installation,
then stable user, Homebrew and system locations. It deliberately does not copy the entire
interactive PATH, which can contain temporary agent-session or version-manager directories
that disappear while the LaunchAgent keeps running. The same environment also covers
interpreters such as node; hardcoding only the path to claude or codex would not.

Installations with an uncommon tool location can add it without replacing the safe defaults:

[schedule]
extra_path = "~/.local/share/mise/shims"

New schedules get the fix automatically. After upgrading an existing installation, run
regesto --config /path/to/regesto-kb/config.toml schedule install once to rewrite and
reload its current jobs. No fact format or schema changed.