Skip to content

v1.3.1

Latest

Choose a tag to compare

@github-actions github-actions released this 03 Sep 00:36

Release Notes v1.3.1

Released: 2026-09-03

A patch release built around one new capability: sibyl migrate to-team, a self-service path for moving a project's memories from a personal instance into a shared team server. The rest of the release is the version bump across app dependencies, container tags, Helm charts, and Ansible defaults.

🌟 Highlights

✨ Self-service migration into a team server

New sibyl migrate to-team command (apps/cli/src/sibyl_cli/migrate.py) replays a project's verbatim raw captures into a team server through the ordinary authenticated API, as the calling user. Ownership lands on the caller's target identity by construction, and the target re-projects and re-embeds server-side. On the target side no SSH, kubectl, or operator credentials are needed, so any teammate can run it with their own SSO login. The source side still reads the local content store directly with its own SurrealDB credentials (--source-surreal-user, SIBYL_SOURCE_SURREAL_PASS).

♻️ Re-runnable by design

Every successful post is recorded in a per-route ledger under ~/.sibyl/migrations, keyed and manifest-pinned to source org + target context + target project. Interrupts and repeat runs skip what already moved. A ledger whose manifest does not match the current route raises instead of silently suppressing writes.

📝 Migration skill pack guidance

apps/cli/src/sibyl_cli/data/skill-packs/migration.md gains a to-team replay section covering when to use the replay lane over the operator-shaped archive/consolidate lane, the one-time per-person context and login setup, and what to verify after a run.

🤖 Migration command details

  • Scope is narrow. Only raw captures with memory_scope=project and the given scope_key move. Private memories stay local.
  • Target project resolution. --target-project accepts an exact id or a name; exact project_ ids resolve directly via get_entity, so projects outside the listing window stay reachable. Ambiguous names fail with the candidate ids listed. Without --target-project, the command falls back to the source project's display name.
  • Provenance is preserved. Each replayed record carries provenance.migration with the origin org, origin raw id, original created_at, capture surface, and the untruncated original title when the title exceeds 300 characters.
  • Project id rewriting. metadata.project_id is rewritten to the target project id (the original is kept in provenance) because the retrieval layer prefers metadata over the scope key, and a copied source id would misroute the memory.
  • Source org inference. --source-org is optional; the command groups raw_captures by organization_id and fails with the candidates listed when more than one org carries the scope.
  • Paged reads. Source rows are fetched 200 at a time over SurrealDB HTTP /sql against the sibyl_content namespace, ordered by created_at.
  • --dry-run counts without writing, and --limit N caps a run.
  • Per-row failure handling. Empty bodies and content over 500,000 characters are recorded as failures rather than aborting the run. The summary prints migrated, skipped, and failure counts; only the first 10 failure lines are shown, and the command exits non-zero when any row failed.
  • Credential hygiene. --source-surreal-pass reads SIBYL_SOURCE_SURREAL_PASS so passwords stay out of shell history.

The command is registered in apps/cli/src/sibyl_cli/main.py under sibyl migrate.

🔨 Deployment

Version moves to 1.3.1 across:

  • VERSION
  • sibyl-core pins in apps/api/pyproject.toml and apps/cli/pyproject.toml
  • sibyl-api, sibyl-worker, and sibyl-web image tags in docker-compose.quickstart.yml and infra/ansible/roles/sibyl/files/docker-compose.yml
  • sibyl_version in infra/ansible/roles/sibyl/defaults/main.yml
  • chart version in charts/sibyl/Chart.yaml and charts/surrealdb/Chart.yaml

charts/sibyl/Chart.yaml bumps both version and appVersion. The sibyl-surrealdb chart bumps only version; its appVersion stays "3.2.3", which tracks the SurrealDB engine, not the Sibyl release. Deployment docs (docs/deployment/helm-chart.md, kubernetes.md, ansible.md, monitoring.md, docs/cli/docker.md, docs/guide/installation.md) were updated to match.

🐛 Known limitations

  • Replayed records get a fresh created_at; the original timestamp lives in provenance.migration.origin_created_at. Decay-aware backdating is a follow-up.
  • The target needs a working embedding key before a run, otherwise ingestion queues projection failures.
  • Records over the 500,000 character API limit must be migrated by hand.

⬆️ Upgrade Notes

  • No breaking changes. Bump image tags or chart versions to 1.3.1 and redeploy.
  • Before migrating, create the destination context and log in: sibyl config context create <team> --server https://<team-server> --use, then sibyl auth login --server https://<team-server>.
  • The target project must already exist on the team server (sibyl project create), or pass --target-project with an existing id.
  • Run with --dry-run first to confirm the counts, then run for real.
  • Run the migration with a CLI at least as new as the target server's release; the server publishes a minimum_client_version floor that fails old clients closed.

Install

Local server

curl -fsSL https://raw.githubusercontent.com/hyperb1iss/sibyl/main/install.sh | sh -s -- --version 1.3.1

Remote CLI

curl -fsSL https://raw.githubusercontent.com/hyperb1iss/sibyl/main/install.sh | sh -s -- --remote --version 1.3.1
sibyl init --remote https://sibyl.example.com
sibyl auth login

Homebrew

brew install hyperb1iss/tap/sibyl
sibyl up

Arch Linux (AUR)

paru -S sibyl
sibyl up

Headless server

curl -fsSL https://raw.githubusercontent.com/hyperb1iss/sibyl/main/install.sh | sh -s -- --version 1.3.1 --no-open

Kubernetes (Helm)

helm repo add sibyl https://raw.githubusercontent.com/hyperb1iss/sibyl/gh-pages
helm repo update sibyl
helm upgrade --install sibyl sibyl/sibyl --version 1.3.1

Artifacts

This release includes Python wheels and sdists, the generated
Homebrew formula, the generated AUR PKGBUILD, Helm charts, Docker
SBOMs, aggregate dual-registry cosign receipts, and a SHA256 checksum
manifest.