The Extreme-BDD board next to every project tool you’ve used.
Most planning tools treat the ticket database as the source of truth. Extreme-BDD treats the BDD scenario as the source of truth, then shows it on a board and mirrors it into Radicle issues. The matrix below shows what that swap really changes.
Feature-by-feature matrix
Green ✓ = built-in. Amber · = partial or needs an add-on. Red × = not built on purpose. DIFF = there, but built in a different shape. The Extreme-BDD column is highlighted because this is its home turf.
| Feature | Extreme‑BDD | Hermes Kanban | GitHub Projects + Issues | Jira / Linear | Trello / Asana / Notion | Plane / OpenProject / Taiga | Gitea / Forgejo / sourcehut | git‑bug / Fossil | Generic Radicle UIs | ngit / gitworkshop (NIP‑34) |
|---|---|---|---|---|---|---|---|---|---|---|
| Card body is the BDD Given/When/Then | ✓ | × | × | × | × | × | × | × | × | × |
| Canonical backlog is repo files, not a hosted database | ✓ | DIFF | × | × | × | × | × | ✓ | · | × |
| Board shows uncommitted work (reads the working tree) | ✓ | × | × | × | × | × | × | · | × | × |
| Acceptance criteria travel with the code | ✓ | × | × | × | × | × | × | ✓ | × | × |
| No hosted forge / SaaS in the trust path | ✓ | ✓ | × | × | × | · | · | ✓ | ✓ | ✓ |
| Self-hostable end to end | ✓ | ✓ | × | × | × | ✓ | ✓ | ✓ | ✓ | ✓ |
| Distributed issue tracking (no central server) | ✓ | × | × | × | × | × | × | ✓ | ✓ | ✓ |
| Kanban / drag-drop board | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | × | × | × |
| Ghost cards for non-canonical branches / patches | ✓ | × | × | × | × | × | × | × | × | · |
| Patch / branch discovery in the board | ✓ | × | ✓ | · | × | · | ✓ | × | · | ✓ |
| Evidence-driven lifecycle (Done requires PMCI/local test status) | ✓ | × | × | × | × | × | × | × | × | × |
| Read-only seed-hosted viewer (no private keys exposed) | ✓ | × | × | × | × | × | × | × | · | ✓ |
| Velocity / burndown / Done-week rollups | ✓ | · | ✓ | ✓ | · | ✓ | · | × | × | × |
| Gantt / timeline view | ✓ | × | ✓ | ✓ | · | ✓ | × | × | × | × |
| Custom-fields editor / enterprise workflow admin | × | · | ✓ | ✓ | · | · | · | × | × | × |
| Real-time multi-user editing | × | · | ✓ | ✓ | ✓ | ✓ | ✓ | × | × | · |
| Zap / payment signal on patches and contributors | × | × | × | × | × | × | × | × | × | ✓ |
| Requires Git/Radicle/BDD literacy | DIFF | DIFF | × | × | × | × | DIFF | DIFF | DIFF | DIFF |
“Requires Git/Radicle/BDD literacy” is an honest trade-off, not a win. If your team won’t write Given/When/Then, the spec-as-backlog idea can’t work. The rest of the matrix is what you get in exchange.
How each alternative differs
Hermes Kanban
Harness-native task board for named agent profiles, durable SQLite rows, dispatcher-spawned workers, CLI/slash/dashboard control, andkanban_* lifecycle tools.
Hermes Kanban is a real board, but it is a different primitive: the canonical task state lives in Hermes’s Kanban database, not in repo-tracked BDD files. Its strength is agent orchestration — tasks, tenants, workspaces, worker lanes, retries, comments, blocking, completion, and audit trail. Extreme-BDD is stricter about product truth: a card is a BDD scenario in the repository, and Done is projected from current test evidence.
GitHub Projects + Issues
Issues, boards, custom fields, automation, PR linkage.
With GitHub, the issue database is usually the source of truth.
Extreme-BDD keeps the backlog in tracked .feature
files and mirrors metadata into Radicle issues.
GitLab Issue Boards
Issue cards move through workflow lists, similar to Kanban/Scrum boards.GitLab is a server-based forge. Extreme-BDD runs on your laptop and uses Radicle. It reads your files, Radicle issues, your DID, who you follow, and updates from gossip.
Jira / Linear
Prioritized work, assignees, workflow states, roadmaps, issue discussions.These are general project management tools. Extreme-BDD puts the spec first. Cards are BDD scenarios with Given/When/Then acceptance tests built in.
Plane / OpenProject / Taiga
Open-source or self-hostable project management with boards, cycles, roadmaps, and docs.These tools track work in their own databases. Extreme-BDD keeps the plan next to the code and uses Radicle to share it.
Gitea / Forgejo / sourcehut
Self-hosted forge features: repos, issues, pull/merge requests, projects, CI.These swap GitHub or GitLab for another forge. Extreme-BDD doesn’t host Git. It’s a workflow layer on top of Radicle repos, issues, patches, and seed viewers.
Generic Radicle clients / web UIs
Radicle repos, issues, patches, identities, and seed visibility.Generic Radicle UIs show raw forge objects. Extreme-BDD turns those objects into BDD backlog cards, board columns, ghost cards, drift warnings, feedback queues, and “Continue work” commands.
ngit / gitworkshop.dev (NIP‑34)
Decentralized git collaboration over Nostr. Patches, issues, repo state, and clone URLs travel as Nostr events through commodity relays.ngit is the Nostr-side peer to Radicle. The protocol is NIP‑34: patches are kind‑1617 events, issues are kind‑1621, repo state is kind‑30617/30618. Discovery is real-time over relays you already use for chat and zaps. No kanban, no ghost cards, no Given/When/Then — same patch-discovery shape, different surface. Extreme-BDD adds the board, the BDD lifecycle, and the adoption pill on top, and the ngit / NIP‑34 compatibility epic lets the board accept Nostr-published patches as ghost cards alongside Radicle namespaces. Zaps come along for free as an economic signal next to the technical adoption count.
rad clone rad:zdUFqQEWVNeMmdzeHpDyHrDpimWm
$EDITOR radicle-priorities/docs/EPIC__NGIT_NIP34_COMPATIBILITY.md
$EDITOR radicle-priorities/bdd/features/ngit_nip34_compatibility.feature
No rad yet? See
Getting started for the
one-line install. The whole site eats its own dog food —
this is how every contributor reads our source.
git-bug / Fossil SCM
Distributed/offline issue tracking tied to version control.
These make decentralized tickets first-class. Extreme-BDD uses
Radicle’s issue and patch model. It also keeps
.feature scenarios as the backlog and spec.
Trello / Asana / Notion projects
Visual task boards, cards, lists, timelines, lightweight planning.These tools are detached from the code. Extreme-BDD builds the board straight from repo files, Radicle issue state, test results, and sync state.
radicle-seed-kit complementary
Seed provisioning, private mirroring, restricted tunnels, seed sync, privacy guardrails, Tor/multi-seed resilience, and Circle Source governance.
Seed Kit makes the work available. Extreme-BDD plans the work. It reads BDD scenarios, issues, patches, CI/CD test results, seed status, and gossip state. The two tools ship together.
When this is a good fit
It’s a better fit when your team wants:
- acceptance tests that live with the code;
- planning that works before you commit, but shares through Git or Radicle;
- your own seed to host private repos, test results, and read-only dashboards — no SaaS forge in charge;
- issue discussion that can’t silently overwrite the spec;
- a way to find in-progress patches without a central fork graph;
- a read-only seed-hosted view that doesn’t expose private keys.
It’s a worse fit when your team mainly wants:
- a general project management database with custom fields, automations, and reporting plugins;
- real-time multi-user editing and chat-style discussion inside cards;
- enterprise workflow admin (workflows, permissions, big-team audits);
- a tool that doesn’t ask for Git, Radicle, or BDD skills.