From bf7d51a73f7e1140d52bc0573856acfefdd1f468 Mon Sep 17 00:00:00 2001 From: beads/crew/emma Date: Wed, 14 Jan 2026 20:58:58 -0800 Subject: [PATCH] docs: deprecate EXTENDING.md custom tables approach MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add deprecation notice explaining: - SQLite → Dolt migration removes custom table support - External integrations should use standalone sync tools - Point to jira-beads-sync as the model Co-Authored-By: Claude Opus 4.5 --- docs/EXTENDING.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/EXTENDING.md b/docs/EXTENDING.md index ee90ac11..f3f12dd1 100644 --- a/docs/EXTENDING.md +++ b/docs/EXTENDING.md @@ -1,5 +1,16 @@ # Extending bd with Custom Tables +> **⚠️ DEPRECATED**: This document describes extending bd via custom SQLite tables. +> This approach is being deprecated as bd migrates from SQLite to Dolt as the +> storage backend. Dolt does not support hosting custom tables in the same database. +> +> **For external integrations** (syncing with Jira, Shortcut, Linear, etc.), build +> a standalone sync tool following the pattern of [jira-beads-sync](https://github.com/conallob/jira-beads-sync). +> These tools use bd's CLI with `--json` flags or read/write the `.beads/` JSONL files directly. +> +> **For orchestration layers**, consider using a separate database that references +> bd issue IDs, or wait for the forthcoming plugin architecture. + bd is designed to be extended by applications that need more than basic issue tracking. The recommended pattern is to add your own tables to the same SQLite database that bd uses. ## Philosophy