ClickUp task provider integration: preferred PR structure?

[nsxdavid]

Hi, I have been working on first-party ClickUp support for Orca and now have a working implementation in my fork. Before opening an upstream PR, I would like some guidance on how you would prefer this packaged.

The implementation currently includes:

• Personal access token authentication, including testing, replacement, and disconnect
• Local and SSH runtime support
• Workspace, space, folder, list, task, and subtask browsing
• All Tasks and supported saved list views
• Grouping, configurable columns, and subtask display controls
• On-demand loading for nested subtasks
• Task and subtask creation
• Editing status, priority, task type, tags, and assignees
• Task details and threaded comments
• Starting an Orca workspace from a ClickUp task
• Preserving the linked ClickUp task on folder workspaces

Here is the current task list UI:

The implementation is available in this review PR on my fork:

nsxdavid#3

That PR currently passes the fork's CI checks, and its review findings have been addressed.

This touches several parts of Orca because a task provider crosses authentication, runtime RPC, persistence, settings, task browsing, workspace creation, and the task detail UI. The current branch is intended to be usable as a complete integration rather than a partial foundation.

Would you prefer this submitted as one complete upstream PR, or as a staged series? If staged, where would you prefer the first boundary to be?

I am happy to adjust the structure before opening the upstream PR.

[nwparker]

Hey! We're adding an extension system!

Task managers is one of these. So this will slot nicely there.
Trying to target this or next week.

BTW: sorry for the delay!