Skip to content

feat: initiatives with full CRUD and project linking#114

Draft
lightstrike wants to merge 3 commits intoflipbit03:mainfrom
lightstrikelabs:feat/initiatives
Draft

feat: initiatives with full CRUD and project linking#114
lightstrike wants to merge 3 commits intoflipbit03:mainfrom
lightstrikelabs:feat/initiatives

Conversation

@lightstrike
Copy link
Contributor

Summary

  • Add new top-level initiatives command with list, read, create, update, archive, unarchive, and delete subcommands
  • Add initiatives projects add and initiatives projects remove for linking/unlinking projects
  • Add resolve_initiative_id() helper for name-to-UUID resolution
  • Generate initiatives, initiative queries and 7 mutations via codegen
  • Include offline tests (help, validation) and online tests (CRUD lifecycle, archive/unarchive, project linking)

Test plan

  • cargo build --workspace compiles
  • cargo clippy --workspace -- -D warnings clean
  • cargo fmt --check passes
  • Offline tests pass (5 new)
  • SDK online tests pass (initiative_create_update_and_delete, initiative_to_project_create_and_delete)
  • CLI online tests pass (initiatives_create_update_and_delete, initiatives_archive_and_unarchive, initiatives_projects_add_and_remove)

Note: Online tests depend on #105 (configurable test team env var) for reliable execution.

The previous approach tried to create a duplicate link to get the join
entity ID, but Linear rejects duplicate initiative-to-project links.
Instead, query the project's initiative_to_projects connection to find
the existing join entity and delete it.
@flipbit03
Copy link
Owner

Hey @lightstrike — thanks for your enthusiasm and all these contributions! We just released v2.0.0 which includes several of your earlier contributions — great work!

Quick heads-up on workflow: with multiple draft PRs open at once, they tend to go stale fast as main moves forward and earlier PRs get merged (causing conflicts in later ones). Looking at our recent merged PRs (#88, #91, #92, #106, #107, #108, #112), I had to push 30+ commits across your branches — merge conflict resolution, rebasing on main, reworking implementations, fixing tests, updating docs — on top of your original work. I'm happy we got all of that shipped together, but that level of serial branch maintenance isn't sustainable on my end going forward.

To keep things smooth, it'd be great if you could pick the one you'd like to land first, rebase it on the latest main, and mark it as ready for review. Once that's merged, move on to the next one, and so on. That way each PR is up to date and reviewable, and we avoid a pile-up of conflicts.

Also, going forward — for PRs that involve design or architectural changes, please open an issue first so we can discuss the approach before code is written. That way we align on direction early and avoid wasted effort on both sides. (See #115#126#127 as an example of how that played out.)

Tag me (@flipbit03) when it's ready for review. Looking forward to it!

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