Steve Cliff
22d5848e1a
- Introduced `openspec-sync-specs` skill to sync delta specs to main specs, allowing intelligent merging of requirements. - Added `openspec-verify-change` skill to verify implementation against change artifacts, ensuring completeness, correctness, and coherence before archiving. docs: Create CLAUDE.md for project guidance - Added CLAUDE.md to provide an overview of the PCLI project, including build, test commands, architecture, and resource addition guidelines. chore: Add new change and design documents for project filter in status command - Created `.openspec.yaml`, `design.md`, `proposal.md`, and `tasks.md` for the `add-project-filter-to-status` change. - Updated specs for CLI commands and status command to include project filtering functionality. feat: Expand board included parsing in API client - Added parsing for `labels`, `cardLabels`, and `cardMemberships` in the `GetBoard` response. - Updated `ListCardsByBoard` to enrich card output with label names, enhancing usability in kanban sync workflows.
2.6 KiB
Context
The Planka v2 API GET /api/boards/:id response includes an included object with: users, boardMemberships, labels, lists, cards, cardMemberships, cardLabels, taskLists, tasks, attachments, customFieldGroups, customFields, customFieldValues. Currently GetBoard only parses lists and cards, discarding everything else.
The CardLabel and Label types already exist in model/types.go. The Board struct has Lists and Cards fields but not Labels, CardLabels, or CardMemberships.
Goals / Non-Goals
Goals:
- Parse
labels,cardLabels, andcardMembershipsfrom theGetBoardresponse - Make label data available on the
Boardstruct for downstream consumers - Enrich
ListCardsByBoardoutput socard list --boardincludes label names per card
Non-Goals:
- Parsing all included fields (users, taskLists, attachments, customFields, etc.) — only what's needed now
- Adding label data to
card list --list(uses a different API endpoint that doesn't include labels) - Changing the
card getresponse (already returns card-level data via a different endpoint)
Decisions
Add fields to Board struct rather than creating a separate BoardDetail type
Decision: Add Labels, CardLabels, and CardMemberships as optional fields on the existing Board struct with omitempty.
Alternative: Create a BoardDetail struct for the enriched response. Rejected — the fields are simply absent when not fetched (e.g., ListBoards), and omitempty handles this cleanly without a type split.
Add Labels field to CardWithList for card list --board output
Decision: Add a Labels field ([]string of label names) to the CardWithList struct. ListCardsByBoard will resolve card→label associations via the cardLabels join table and labels list from the board response.
Alternative: Return full Label objects per card. Rejected — label names are sufficient for display and filtering; full objects add noise to output.
Use join-table approach matching the API structure
Decision: Keep CardLabel as the join entity (cardId + labelId), and resolve to label names at the point of use (in ListCardsByBoard). This mirrors the Planka API's relational structure.
Risks / Trade-offs
- [Additive JSON fields] →
card list --boardoutput will include a newlabelsarray per card. Existing consumers that don't use this field are unaffected. Scripts using strict JSON parsing may need updating. - [Partial included parsing] → We still skip users, taskLists, attachments, etc. This is intentional — parse only what's needed. Future changes can add more fields incrementally.