Skip to content

fix: normalize bd/br schema and canonical blocked state - #20

Open
craigk wants to merge 2 commits into
w3dev33:masterfrom
craigk:bd-schema-compatibility-pr
Open

fix: normalize bd/br schema and canonical blocked state#20
craigk wants to merge 2 commits into
w3dev33:masterfrom
craigk:bd-schema-compatibility-pr

Conversation

@craigk

@craigk craigk commented Aug 19, 2026

Copy link
Copy Markdown

Summary

The client currently assumes an older JSON shape from the external issue-management CLI. Several fields have changed names or types, and relationship data does not directly represent current blocked state.

This can cause valid records to be rejected during deserialization, fields to be silently discarded, and dashboard state to differ from the CLI.

This PR normalizes those differences at the adapter boundary and propagates canonical blocked state through the client.

Compatibility scope

Client Version Observed output
bd 0.49.6 Object metadata, estimated_minutes, owner, and dependencies
bd 1.2.2 Object metadata, estimated_minutes, owner, and dependencies
br 0.1.33 Paginated JSON envelope, estimated_minutes, and owner; metadata may be absent
br 0.2.19 Current installed version; complete comparison requires clean JSONL output

This is a schema-shape compatibility fix. It does not claim that a particular minor-version transition introduced the defect.

Older output using string metadata and estimate remains supported.

Defects addressed

  • Accept object-valued metadata while preserving legacy string metadata.
  • Map estimated_minutes to the client’s estimate field.
  • Use owner when the client’s assignee field is absent.
  • Read dependency relationships from the CLI’s dependencies field.
  • Resolve current blocked state through the CLI’s canonical blocked command.
  • Preserve relationship data separately from current blocked state.
  • Avoid interpreting historical dependency relationships as currently blocked.
  • Handle CLI differences in pagination and command flags.
  • Prevent stale blocked relationships from surviving a refresh.

Design

The adapter converts each supported CLI representation into one internal issue model.

The internal model distinguishes:

  • blockedBy / blocks: dependency relationships
  • isBlocked: current resolved blocked state

The canonical blocked command is authoritative for isBlocked. Relationship arrays remain available for dependency display and reverse-link construction.

No changes are made to the external CLI or its database schema.

Commit structure

This PR intentionally contains two logical commits:

  1. fix: normalize bd/br issue schema at adapter boundary

    • Raw schema compatibility
    • CLI execution differences
    • Adapter transformation
    • Canonical blocked-data retrieval
    • Adapter regression tests
  2. fix: align dashboard blocked state with beads CLI

    • isBlocked propagation through polling and API helpers
    • Dashboard calculations
    • Issue-table blocked indicators
    • Frontend regression tests

The commits remain in one PR because the first establishes the correct adapter contract and the second consumes that contract in the UI.

Tests and verification

  • Frontend tests: 230 passed
  • Rust unit tests: 14 passed
  • Vue type checking passed
  • Frontend production build passed
  • Rust release build passed
  • macOS application bundle build passed
  • git diff --check passed

The repository’s existing cargo fmt --check baseline reports unrelated formatting differences outside this change; this PR does not mass-format that pre-existing code.

Draft review follow-ups

A read-only review found no critical issues, but identified these items for resolution before merge:

  • Include canonical blocked fields in polling change detection so dependency-only transitions refresh correctly.
  • Use a dedicated canonical-blocked filter for open issues that are blocked by dependencies.
  • Add dependency-object fixtures to the shared blocked-state normalization coverage.
  • Preserve metadata in the server/web adapter path as well as the native path.

Scope exclusions

  • No changes to the CLI.
  • No database migration.
  • No lockfile updates.
  • No generated artifacts.

@craigk
craigk marked this pull request as ready for review August 19, 2026 06:14
@w3dev33

w3dev33 commented Aug 19, 2026

Copy link
Copy Markdown
Owner

Thanks for the detailed write-up - the analysis of the schema drift is careful and the blockedBy/blocks vs isBlocked distinction is the right mental model.

This one I have to decline on scope rather than quality. Your compatibility table targets bd 1.2.2 and br 0.2.19, and that's exactly the boundary this project deliberately doesn't cross. As the README explains: "We follow the Beads CLI - we don't define the format, we read what it writes... If it ever becomes purely machine-to-machine, we freeze at the last meaningful version." The tracker is intentionally frozen at bd 0.49.x / br <= 0.1.33, and chasing the newer CLI schema shapes is the work that has moved to its successor, PaiR (own storage format, built-in CLI, automatic migration from bd 0.49.x / br <= 0.1.33).

If you need this codebase to keep up with current bd/br, you're very welcome to maintain it in your own fork - you already have the work in craigk/beads-task-issue-tracker, and if that fork turns into a maintained continuation I'm happy to link it from the README. But for me, this is where PaiR takes over by design, and I'd genuinely welcome your input there.

So the fixes here aren't wrong, they're just aimed at a version window this project no longer tracks by design. Appreciate the effort.

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.

2 participants