Skip to content

v0.53.0.0

Choose a tag to compare

@github-actions github-actions released this 23 Sep 13:52
976cff5

Keep what your agents know and how they work in the same brain. New local brains now create a content directory containing both knowledge and useful memory skills. Connected agents can discover the same published instructions instead of maintaining unrelated copies. An explicitly authorized editor can update a skill once, and other connections can fetch the same committed version, including its approved supporting files.

Connecting a managed coding agent also installs an owned brain router in its skill directory. Claude Code, Codex and opencode still need a restart, and an installed file is not proof that a native session used it. Other clients receive portable discovery and clear instructions when their own enablement controls are required.

Existing brains are not silently made more public. Previously approved instruction sharing remains prose-only. Personal edits are preserved, and permission to write memories does not grant permission to rewrite shared skills or execute downloaded scripts.

How to use it

New host grants follow published skills by default; choose --skills memory-only to opt out. Existing grants stay unchanged unless explicitly updated. Use list_skills with schema_version: 2, then fetch the chosen qualified skill and revision with get_skill. Shared editors additionally require skill_editor and an explicit operation grant.

Situation What happens
Fresh local initialization Knowledge and packaged memory skills share a recorded content root. Git is optional.
Another agent updates a skill Readers fetch the new complete revision; conflicting edits are rejected.
An old brain is upgraded A staged migration records content, ownership and client actions without overwriting edits or expanding disclosure.
A client cannot check freshness Enforced adapter admission blocks stale use; advisory native integrations do not claim stronger guarantees.

To take advantage of v0.53.0.0

  1. Run gbrain upgrade, then inspect gbrain apply-migrations --dry-run --json.
  2. On an existing file-backed brain, stop older writers and skill-serving processes, review writer status, and follow the migration checklist's state-bound claim and activation steps. Shared-skill activation requires explicit administration intent and the reviewed state; quiescence alone is not authority. Re-run gbrain apply-migrations --yes to finish eligible mechanical stages.
  3. Read skills/migrations/v0.53.0.0.md for explicit follow grants, DB-only export, local conflicts and verification. Reconnect each intended harness; do not count disconnected or native-unverified clients as finished.
  4. See shared brain skills for scoped editing, disclosure policy, exact-version retrieval and recovery. Keep an operational database backup: Git content does not contain grants, delivery receipts or revocation history.

Itemized changes

  • Add source-qualified sealed skill revisions, bounded approved assets, compare-and-swap publication and durable replay through the canonical writer. Schema migration 164 adds the catalog, enrollment records and protocol guards.
  • Add join_brain, sync_brain_skills, leave_brain, put_skill, delete_skill, get_skill_asset and set_skill_policy, with explicit named capabilities and source/operation fences. Discovery joins the starter surface; the seven memory verbs remain unchanged.
  • Serve shared skill resources through the same authorized operations. Existing catalog clients receive compatible prose envelopes after canonical adoption.
  • Install namespaced, ownership-tracked routers and immutable local revision caches, with separate transport, artifact and native-use status. Preserve edited files on update and removal.
  • Add staged combined-content migration, compile-safe default memory skills and explicitly approved DB-only content export with round-trip checks. Existing publishing opt-outs, private files and grant ceilings survive upgrades.
  • Keep fresh-install upgrades compatible with canonical files: grandfathering uses durable metadata publication, preserves existing search projections and vectors, and does not enqueue embedding or fact-extraction work for the compatibility flag.