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.
38 lines
2.6 KiB
Markdown
38 lines
2.6 KiB
Markdown
## 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`, and `cardMemberships` from the `GetBoard` response
|
|
- Make label data available on the `Board` struct for downstream consumers
|
|
- Enrich `ListCardsByBoard` output so `card list --board` includes 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 get` response (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 --board` output will include a new `labels` array 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.
|