Skip to content

Make the debugging skill aware of doltlite backends (agnostic — detect + trace to the owning layer) - #1

Draft
Wldc4rd wants to merge 1 commit into
masterfrom
doltlite-backend-plugin-awareness
Draft

Make the debugging skill aware of doltlite backends (agnostic — detect + trace to the owning layer)#1
Wldc4rd wants to merge 1 commit into
masterfrom
doltlite-backend-plugin-awareness

Conversation

@Wldc4rd

@Wldc4rd Wldc4rd commented Jul 5, 2026

Copy link
Copy Markdown
Owner

Charlie's ask (2026-07-04): update gc-debug to accommodate cities on the new DoltLite backend-plugin — the pack assumed Dolt.

What was wrong

The skill modeled the data plane as the Dolt mysql sql-server (SHOW PROCESSLIST, a TCP port, DOLT_GC over the wire) and treated doltlite as a generic raw SQLite file. It had no notion of the current backend-plugin deployment: bd/gc run plain (unlinked) and speak to bd-backend-doltlite serve (stdio) + gc-doltlite-fastpath serve; the store is .beads/doltlite/*.db; there is no TCP server to introspect.

What changed (docs only, 3 files)

  • gas-stack-map: a detect-the-backend-FIRST recipe (.beads/metadata.json is ground truth) + the data plane split into the three real deployments (dolt sql-server / doltlite linked / doltlite backend-plugin). Notes that backends can coexist per-city on a shared box (true right now on coutts-hq).
  • gc-diagnostic-toolkit: the sql-server section tagged dolt-only; the doltlite section rewritten for the plugin — query via bd sql (not a raw sqlite3 open, which bypasses the working-set/commit model), inspect the …serve procs + store dir, use DoltLite SQL maintenance functions; defers to the authoritative beads-doltlite skill for dolt_gc/flatten/locks/fastpath.
  • SKILL: the stack tree reflects the pluggable backend.

Grounded against the live house-staff city (now on the plugin) — the detection commands and proc names are real, not invented.

Draft for your review, sir. Merge to master when it reads right.

@Wldc4rd
Wldc4rd force-pushed the doltlite-backend-plugin-awareness branch from 2c3fed6 to 2ed077e Compare July 5, 2026 00:27
@Wldc4rd Wldc4rd changed the title Teach the debugging skill the DoltLite backend-plugin (not just Dolt) Make the debugging skill aware of doltlite backends (agnostic — detect + trace to the owning layer) Jul 5, 2026
@Wldc4rd
Wldc4rd force-pushed the doltlite-backend-plugin-awareness branch from 2ed077e to 616427f Compare July 5, 2026 00:34
…torializing)

The pack modeled the data plane as the Dolt mysql sql-server (PROCESSLIST,
a TCP port, DOLT_GC over the wire) and treated doltlite as a raw SQLite file.
It had no notion of the DoltLite backend-plugin deployment: bd/gc run plain
(unlinked) and speak to `bd-backend-doltlite serve` (stdio) + `gc-doltlite-fastpath
serve`, store at `.beads/doltlite/*.db`, no TCP server.

Keep the skill backend-agnostic — its job is to detect a store's backend and
trace to the OWNING LAYER's repo, not to rank backends:
- gas-stack-map: a "detect the backend FIRST" recipe (`.beads/metadata.json` is
  ground truth) listing the common backends + their repos, explicitly leaving the
  set open (others may exist). No official/default/legacy framing.
- gc-diagnostic-toolkit: tag the sql-server section as dolt-only; give the doltlite
  section the plugin model — query via `bd sql` (not a raw `sqlite3` open), inspect
  the `…serve` procs + store dir, use DoltLite SQL maintenance functions; defer to
  the `beads-doltlite` skill for dolt_gc/flatten/locks/fastpath.
- SKILL: reflect the pluggable backend in the stack tree.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@Wldc4rd
Wldc4rd force-pushed the doltlite-backend-plugin-awareness branch from 616427f to a95e0ea Compare July 5, 2026 00:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant