Skip to content

Releases: BolivarTech/SBTDD

v0.1.1

Choose a tag to compare

@BolivarTech BolivarTech released this 08 Jun 03:31

/sbtdd-check Check 8 — Active MAGI backend

/sbtdd-check now reports which MAGI backend the SBTDD flow will use and, when the Ollama backend is selected, smoke-tests it end-to-end before you hit a gate.

Added

  • Check 8 — Active MAGI backend in the read-only /sbtdd-check verifier:
    • Reports the active backend by the presence of ./.claude/magi-ollama.toml (Claude default vs Ollama).
    • When Ollama is active, runs a real end-to-end smoke test via the interactive magi:magi --ollama skill on a throwaway input — surfacing a broken backend (daemon down, no ollama signin, missing trio model, MAGI < 4.0.1) as a FAIL with MAGI's own error, before a gate rather than during one.
    • Explicit, exhaustive PASS/FAIL classification (including an incomplete / no-verdict run), a preflight time-bound note, and privacy / cloud-cost / non-interactive notes.
  • A cross-reference to Check 8 from the normative review-gates.md §8.
  • README documents the new verifier capability.

Notes

  • The smoke test honors the interactive-only contract (§7): no claude -p, no direct runner subprocess.
  • No MAGI plugin changes; the Ollama backend requires MAGI 4.0.1+.

Full Changelog: v0.1.0...v0.1.1

v0.1.0 — MAGI Ollama backend

Choose a tag to compare

@BolivarTech BolivarTech released this 08 Jun 00:09

v0.1.0 — MAGI Ollama backend

Force the Ollama MAGI backend across the SBTDD flow.

Added

  • /sbtdd-init --ollama-init — scaffolds ./.claude/magi-ollama.toml (delegates to MAGI's --ollama-init), enabling the Ollama backend.
  • /sbtdd --ollama — run/resume on the Ollama MAGI backend; explicit fail-closed form.
  • review-gates.md §8 — MAGI Backend Selection — single normative contract: backend resolved by presence of ./.claude/magi-ollama.toml (auto across resumes); fail-closed when the toml is absent or the backend is unavailable (never silently falls back to Claude); remove the toml to switch back; consistent with the §7 interactive-only contract.

Notes

  • Requires MAGI 4.0.1+ for the Ollama backend.
  • Anti-duplication preserved (SKILL.md, commands/*, routing.md point to §8).
  • Docs-only plugin change; 58 presence/lint tests pass. Reviewed via requesting-code-review + a 2-iteration MAGI gate (STRONG GO).

Full Changelog: v0.0.5...v0.1.0

v0.0.5 — MAGI interactive-only contract

Choose a tag to compare

@BolivarTech BolivarTech released this 29 May 00:58

v0.0.5 — MAGI interactive-only contract

Documents /magi:magi as an interactive-only Claude Code skill in the SBTDD references and forbids headless invocation via claude -p captured-pipe subprocess. Addresses the MAGI-Hang Windows stdio-chain incident by ensuring future runtimes read an explicit contract before invoking the review gate.

What's new

  • New §7 "MAGI Invocation Contract" in skills/sbtdd/references/review-gates.md. Self-contained: names the forbidden transport (claude -p "/magi:magi …"), enumerates the Windows failure mechanisms (pipe-buffer deadlock, asyncio.ProactorEventLoop hang on create_subprocess_exec under inherited non-TTY stdin, stdin reads against closed pipes), and lists the two supported alternatives (interactive handoff; direct magi-runner CLI invocation if/when published).
  • interactive-only pointers at 6 documentation surfaces so a reader entering at any entry point encounters the contract before building a headless dispatcher:
    • SKILL.md delegation-table Plan-gate row + Pre-merge review row + §4 Gates blockquote
    • references/routing.md plan-gate row Action cell
    • references/review-gates.md §0 Plan Gate + §4 Final Gate blockquotes
    • README.md phase table
  • 5 new presence/lint tests plus Loop 1/Loop 2 hardenings:
    • §7 polarity guard — no line presents claude -p co-located with permitted / acceptable / now allowed / is supported / no longer applies
    • Supported-alternative bullet anchors (- **Interactive handoff.**, - **Direct runner invocation.**)
    • §0/§4 first-line header cross-check (Plan Gate / Final Gate) guarding against silent wrong-section matches
    • SKILL.md per-surface row anchors with >=2 count fallback
  • Tightened .gitignore from a broad docs/MAGI-Hang* pattern to explicit filenames (docs/MAGI-Hang.txt, docs/MAGI-Hang-Handoff.md), so future tracked post-mortems aren't silently hidden.

Quality gates

  • pytest 51/51 passing
  • Loop 1 (superpowers:requesting-code-review) clean-to-go after 3 refactor: mini-cycles
  • Loop 2 (magi:magi interactive gate) verdict GO WITH CAVEATS (3-0) — all Caspar conditions applied as low-risk doc/test fixes per CLAUDE.local.md §6

Scope

This release is documentation only. The MAGI-Hang runtime fix itself lands in a separate SBTDD-runtime repository; the contract here ensures any future headless runtime reads the prohibition before invoking the review gate.

Install

/plugin install BolivarTech/SBTDD@v0.0.5

v0.0.4 — Enforce Checkpoint 1 (manual plan review) before MAGI

Choose a tag to compare

@BolivarTech BolivarTech released this 26 May 00:30

Summary

The sbtdd orchestrator now enforces Checkpoint 1 (manual human review of the original plan) as an ordered gate before Checkpoint 2 (the MAGI review) in the plan gate, matching the canonical flow in the scaffolded CLAUDE.local.md §1. Previously the routing collapsed both into a single MAGI step and Checkpoint 1 was not enforced.

Changes

  • references/routing.md — the plan-gate decision-table row is now "Plan gate (Checkpoint 1 → Checkpoint 2)": Checkpoint 1 stops for manual review of claude-plan-tdd-org.md; on reject it re-runs superpowers:writing-plans with the feedback; Checkpoint 2 (MAGI) runs only after Checkpoint 1 is approved.
  • references/review-gates.md — new "## 0. Plan Gate" section describing Checkpoint 1 (criteria, reject loop-back) chaining into the MAGI loop, pointing to CLAUDE.local.md §1 (no rule-table duplication).
  • SKILL.md — delegation row reordered to manual review (Checkpoint 1) → magi:magi (Checkpoint 2); the Gates section names both ordered stops and states MAGI never runs before Checkpoint 1 is approved.
  • Tests — three row/section-scoped presence tests lock the Checkpoint 1 → Checkpoint 2 ordering and the reject loop-back.

Design

Approach A — the two checkpoints run as an ordered in-phase sequence within the single plan-gate phase (they share the same file-state window), so no new artifact and no session-state.json field were added.

Verification

  • Full pytest suite green (46 tests).
  • Pre-merge code review clean-to-go; MAGI design review verdict STRONG GO.
  • plugin-validator structural validation: PASS.

v0.0.3

Choose a tag to compare

@BolivarTech BolivarTech released this 23 May 23:41

SBTDD v0.0.3

Patch release: broadens the Rust clippy lint scope in the scaffolded verification template.

Changed

  • Rust verification template now uses cargo clippy --all-targets instead of --tests. The previous flag linted only the library, binaries, and tests, leaving examples/ and benches/ unchecked. --all-targets covers the whole crate, matching the Rust CI community convention and the whole-tree scope already used by the Python template (ruff check ., mypy .). The change is a no-op for projects without examples or benchmarks and adds real coverage once those targets exist.

Full changelog: v0.0.2...v0.0.3

v0.0.2

Choose a tag to compare

@BolivarTech BolivarTech released this 23 May 22:41

SBTDD v0.0.2

Patch release: corrects the multi-agent execution model in the orchestrator skill and fixes a .gitignore packaging bug.

Changed

  • Parallel TDD-Guard execution model corrected. Serial execution with TDD-Guard ON (via superpowers:subagent-driven-development) is now documented as the default and preferred mode. Parallel sub-agents are advised only when there is a perceptible time gain and the tasks are mutually independent.
  • The previous guidance that parallel sub-agents in separate worktrees could keep TDD-Guard ON was incorrect — the guard's shared process state conflicts even across separate worktrees. Parallel now requires the full combination: TDD-Guard OFF + one isolated worktree per sub-agent + merge each worktree back to the parent branch on completion, with superpowers:test-driven-development enforcing the cycle.

Fixed

  • Unanchored .gitignore patterns (sbtdd/, planning/, …) matched nested paths such as the plugin's own skills/sbtdd/ directory, silently ignoring new skill files. The developer-local artifact patterns are now anchored to the repository root.

Full changelog: v0.0.1...v0.0.2

v0.0.1 — first release

Choose a tag to compare

@BolivarTech BolivarTech released this 23 May 18:52

First public release of the SBTDD orchestrator plugin for Claude Code — a single, resumable, state-routed /sbtdd entry that drives the Spec + Behavior + Test-Driven Development workflow on top of superpowers and the magi review gate.

Highlights

  • /sbtdd — state-routed orchestrator: spec → plan → MAGI gate → TDD execution → dual-loop review → finalization. Resumes cleanly across sessions via .claude/session-state.json, with drift detection that fails safe.
  • /sbtdd-init — idempotent multi-stack scaffolding (Rust / Python / C-C++), defensive .claude/settings.json merge, and tdd-guard binary gating so a missing binary never bricks the project.
  • /sbtdd-check — read-only environment verifier (rules, hooks, directories, binary, delegated skills).
  • Dual licensed MIT OR Apache-2.0.

Install

/plugin marketplace add BolivarTech/SBTDD
/plugin install sbtdd@bolivartech-sbtdd

Requirements

Requires the superpowers and magi plugins, plus the tdd-guard binary for execution-phase enforcement.

Notes

Built by dogfooding its own methodology (TDD-first, MAGI-gated through a four-iteration pre-merge loop). Structural test suite: 43 passing. Design spec and implementation plan under docs/superpowers/.