[{"content":"Welcome. This is where I write up what I build and the tech I find worth explaining: cryptography, distributed systems, infrastructure-as-code, and the agentic tooling I lean on day to day.\nThe name is a distributed-systems joke — and a promise that the opinions here will converge over time.\nWhat to expect Project write-ups — what I built, why, and what broke. Deep dives — Zen \u0026amp; the art of Technology, People and Tech, Architecture, IAC patterns, other Nerdery. Tooling — the small things that make the work faster. It supports the things I need Code, with copy buttons and syntax highlighting:\n// low-S normalization: half the malleability problem, gone. if s.Cmp(halfN) == 1 { s = new(big.Int).Sub(order, s) } Inline code, callouts, tables, and a table of contents on longer posts.\nMore soon.\n","permalink":"https://www.eventually-consistent.io/posts/hello-eventually-consistent/","summary":"Why this blog exists and what I\u0026rsquo;ll write about here.","title":"Hello World! Welcome to Eventually Consistent"},{"content":"Working with Claude changed how I work I\u0026rsquo;ve been doing this for 28 years. I\u0026rsquo;ve watched a lot of \u0026ldquo;this changes everything\u0026rdquo; tools come and go. Most didn\u0026rsquo;t. Working with Claude did.\nThe shift wasn\u0026rsquo;t that it writes code for me — it\u0026rsquo;s that the unit of work changed. I stopped thinking in keystrokes and started thinking in intent. I describe what I want, Claude drafts it, I review and steer, and the loop is fast enough that I stay in flow instead of context-switching into a dozen tools. Speed went up, but more importantly the friction went down — the tax I used to pay just to keep a project organized mostly disappeared.\nAs I leaned in, I started exploring the plugin ecosystem. Most plugins are nice-to-haves. Two of them changed the way I run projects entirely: Beads and GSD.\nI needed both because I\u0026rsquo;m working solo right now. There\u0026rsquo;s no team to hold the shape of a project in their heads, no standup to surface what\u0026rsquo;s half-finished, no second set of eyes to catch the thread I dropped three days ago. When you\u0026rsquo;re the only one on a project, you are the single point of failure for keeping it all straight — the plan, the open work, the decisions you made and why. That\u0026rsquo;s exactly the kind of bookkeeping that quietly eats a solo developer alive. I didn\u0026rsquo;t want a manager; I wanted the structure a good team gives you, without the team. Beads became my memory for the work, and GSD became the discipline that kept me from wandering — together they hold the project so I don\u0026rsquo;t have to.\nBeads — issues that live where the work lives Beads (bd) is a local-first issue tracker. No web app, no tab to babysit — issues live in a database right next to your code and sync over your git remote. You drive it from the CLI (and so does Claude):\nbd ready # what\u0026#39;s available to work on bd create \u0026#34;…\u0026#34; # file an issue bd update \u0026lt;id\u0026gt; --claim # claim + mark in-progress bd close \u0026lt;id\u0026gt; # done bd prime # full workflow context for an agent What made it click for me: because the issues are local and structured, Claude can read and write them directly as part of doing the work. The tracker stops being a place I go to update status and becomes a byproduct of the work itself. It even keeps a persistent memory (bd remember) so context survives across sessions.\nGSD — turning intent into a plan, then into commits GSD (\u0026ldquo;Get Shit Done\u0026rdquo;) is a planning workflow. Where Beads tracks what, GSD structures how. It breaks a project into a roadmap of phases and walks each phase through a disciplined loop:\ndiscuss → plan → execute → verify → ship Each phase gets its own context, a researched plan, and a verification pass before anything is called done. The commands (/gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:ship) gave me something I\u0026rsquo;d never had consistently: a repeatable, spec-driven cadence that doesn\u0026rsquo;t fall apart the moment a project gets big. Decisions get captured. Plans get checked. Work gets verified instead of just marked complete.\nThe premise: make them work together — and with everyone else\u0026rsquo;s tracker Here\u0026rsquo;s the thing. I had two great tools that didn\u0026rsquo;t know about each other, and a third problem on top: not everyone I work with lives in Beads. They live in GitHub Issues. In Jira. In Asana. In Azure Boards.\nSo I had three jobs to reconcile:\nGSD owned the plan. Beads owned the work items. They didn\u0026rsquo;t talk. Beads was my source of truth, but stakeholders needed to see status in the tool they already use. I refused to double-enter anything. Updating an issue in three places by hand is exactly the friction Claude had just removed. How I got here I started with Beads alone. It was great locally — but I kept wanting those issues mirrored into GitHub so collaborators could follow along without me narrating progress in Slack. So I started wiring Beads to GitHub by hand: create an issue, also open a GitHub issue; close one, close the other. It worked, and it was tedious, and tedious is a smell.\nThen I found GSD, and the picture got bigger. Now I had real phases and real plans — and it was obvious that each plan should close out the tracked work it advanced. The plan and the issues wanted to be the same thing. That\u0026rsquo;s when the idea landed: stop hand-wiring this. Build a plugin that makes GSD and Beads work together natively, and while I\u0026rsquo;m at it, make Beads mirror to any tracker — not just GitHub.\nThe plugin: gsd-beads The result is a Claude Code plugin called gsd-beads. It\u0026rsquo;s deliberately thin glue — it doesn\u0026rsquo;t fork or replace Beads or GSD, it just makes them agree.\nLinking GSD to Beads. Each GSD phase maps its requirements to bd issues in a small map file; every issue carries a phase-N label; every plan declares the bd IDs it advances in its frontmatter. So when a phase is executed, the work it completes is claimed and closed in Beads automatically. The plan and the tracker stay in lockstep.\nMirroring Beads to everything else. This is the part I\u0026rsquo;m happiest with. The design is hub-and-spoke: Beads is the single source of truth, and every external tool syncs to Beads — never tool-to-tool. That keeps the whole thing sane no matter how many trackers you add.\npush (on create / claim / close) bd ───────────────────────────────────► GitHub · GitLab · Jira · Asana · Azure (hub) (spokes) ▲ │ └───────────────────────────────────────────────────┘ pull (on demand) — reconcile back into bd, last-writer-wins by timestamp, conflicts logged Two directions:\nPush fires on Beads lifecycle events — create an issue, claim it, close it, and the matching item is created/updated/closed in every enabled tool. Pull runs on demand and reconciles edits made in those tools back into Beads, using last-writer-wins by timestamp. Genuine both-sides-changed cases get logged as conflicts for me to review instead of silently clobbered. Each tool is a small adapter behind a uniform contract, so adding a new tracker (Linear, Trello, whatever) is one file plus a config block — no changes to the core. Five ship today: GitHub, GitLab, Jira, Asana, and Azure Boards.\nConfiguration lives in a committed sync.json, and — this matters — it only ever stores the names of the environment variables that hold your API tokens. No secrets on disk, ever:\n{ \u0026#34;type\u0026#34;: \u0026#34;jira\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;adapter\u0026#34;: \u0026#34;jira\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;base_url\u0026#34;: \u0026#34;https://yourorg.atlassian.net\u0026#34;, \u0026#34;project_key\u0026#34;: \u0026#34;PROJ\u0026#34;, \u0026#34;email_env\u0026#34;: \u0026#34;JIRA_EMAIL\u0026#34;, \u0026#34;token_env\u0026#34;: \u0026#34;JIRA_API_TOKEN\u0026#34; } } Day to day, I barely think about it. I work in Beads (or let Claude do it as it executes a GSD phase), and the right things show up in GitHub or Jira on their own. When someone edits an issue on their end, a single pull brings it home.\nWhere to get it The plugin is open source (MIT) and lives here:\nGitHub: github.com/BigJiggity/claude-plugins (the gsd-beads plugin under gsd+beads/) Install it as a Claude Code marketplace:\n/plugin marketplace add BigJiggity/claude-plugins /plugin install gsd-beads@claude-plugins I\u0026rsquo;m also working on getting it listed in the Claude plugin marketplace so it\u0026rsquo;s a one-click install. Until then, the marketplace-add command above works today.\nFull docs — architecture, the reconciliation algorithm, per-tool setup, and the adapter contract for adding your own — are in docs/sync.md.\nIt works solo — and it scales to a team I built this for a solo workflow, but the more I used it the more I realized the design is better for teams, not just tolerable for them. The same properties that keep one person straight are the ones that keep a group aligned.\nBecause Beads syncs over your git remote, a team already shares it the moment they share the repo — no server to stand up, no SaaS seat to buy. Everyone works locally, bd ready shows each person what\u0026rsquo;s open, and claiming an issue sets the assignee so two people don\u0026rsquo;t grab the same thing. The tracker rides along with the code instead of living in a separate tab nobody updates.\nGSD gives the team the part that\u0026rsquo;s hardest to maintain by hand: a shared cadence. The roadmap and per-phase plans are the same artifact everyone works from, decisions get captured in context instead of evaporating in chat, and because each plan declares the bd issues it advances, the work that ships is the work that gets closed. New teammates run bd prime and read the phase context to get up to speed in minutes instead of pestering whoever has the project in their head.\nAnd the hub-and-spoke sync is where it really pays off for a group, because no team lives entirely in one tool:\nEngineers stay in Beads (or let Claude drive it as it executes a phase). PMs and stakeholders watch GitHub / Jira / Asana / Azure Boards — whatever they already use — and never have to learn Beads. When someone updates a ticket on their side, a pull reconciles it back into Beads, so the canonical record stays correct without anyone double-entering. Mixed shops work too: front-end on a GitHub Project, the rest of the org on Jira — Beads is the hub, both are spokes, and they don\u0026rsquo;t fight. The net effect is the same thing it does for me solo, scaled up: nobody has to be the human integration layer between the plan, the work, and whatever tracker their teammates happen to prefer.\nWhy this matters to me The whole reason Claude changed my workflow is that it removed friction between intent and done. GSD and Beads each remove a different slice of that friction. Wiring them together — and out to wherever my collaborators actually live — removed the last bit I was still paying by hand.\nOpinions converge over time. So, apparently, do issue trackers.\n","permalink":"https://www.eventually-consistent.io/posts/wiring-gsd-and-beads/","summary":"How working with Claude reshaped my workflow, the two plugins I can\u0026rsquo;t work without, and the plugin I built to make them — and every issue tracker I touch — agree on one source of truth.","title":"Two Claude Plugins, One Source of Truth: Wiring GSD to Beads"},{"content":" I\u0026rsquo;m John Reed — 28 year veteran in tech, SysAdmin, Cloud Architecture, and AI advocate. Im currently tinkering with blockchain, zero-knowledge cryptography, compliance-driven Terraform, and the agentic tooling that keeps it all moving.\nGitHub: @BigJiggity ","permalink":"https://www.eventually-consistent.io/about/","summary":"about","title":"About"}]