fix: filter resolved beans from blocked_by/blocking in JSON output (Refs: beans-k0as)

[SamLeatherdale]

Problem

The blocked_by and blocking arrays in CLI JSON output (beans show --json, beans list --json) and the GraphQL blockingIds/blockedByIds fields return raw frontmatter — they include bean IDs regardless of whether those referenced beans are already completed or scrapped.

This causes agents and scripts to misread a bean as still blocked when all its blockers are already done. For example, a bean with:

"blocked_by": ["beans-b622", "beans-4kki"]

will look blocked to an agent even if both b622 and 4kki have status: completed. The agent has no way to know the dependency is resolved without fetching each blocker individually.

The runtime --ready filter (via findActiveBlockersLocked) already correctly ignores resolved blockers when deciding which beans are available to work on — but the serialized output was not aligned with this behaviour, creating a confusing inconsistency.

This is related to #68.

Fix

Added ActiveBlockedByIds and ActiveBlockingIds methods on Core that walk the frontmatter ID lists and exclude any entries whose referenced beans are completed or scrapped, reusing the existing isResolvedStatus check. Applied in:

• BeanBlockedByIds / BeanBlockingIds GraphQL resolvers
• beans show --json and beans list --json CLI output

After the fix, a bean whose blockers are all completed will have an empty (omitted) blocked_by field in JSON, making its unblocked state immediately clear.

Test plan

• beans show --json <id> for a bean with only completed blockers shows no blocked_by field
• beans list --json similarly omits resolved blocker IDs
• beans show --json <id> for a bean with a mix of active and completed blockers shows only the active blocker IDs
• Unit tests for ActiveBlockedByIds and ActiveBlockingIds pass (go test ./pkg/beancore/...)

Refs: beans-k0as

Made with Cursor