create-project should accept a folder group id #2

New issue

Closed

opened 2026-08-09 19:51:44 -05:00 by mcp-gateway · 0 comments

mcp-gateway commented

2026-08-09 19:51:44 -05:00

Member

Filed from halfst/mpx-engine #120 / #137.

What's needed

ticktick-create-project should take an optional group_id, placing the new project directly into that sidebar folder group.

Why

Sync Operating Spec §4.2 currently records this as a permanent limitation and designs around it:

MCP caveat: create_project can't set a group — auto-created efforts land ungrouped; flag for manual drag.

The engine's card↔effort reconcile is supposed to create a missing effort automatically when a Mission Control card has no paired sidebar project. Because the new project can't be grouped, every auto-creation currently produces an orphan in the sidebar plus a manual chore.

It also forced a code path in the engine: reconcile_registry has an unplaced outcome purely to surface projects that exist but sit in no known folder group, because they can't be filed into a Registry section without a group. With this, that path becomes dead code for anything the sync creates.

list-projects already returns group_id on read, so the field is understood on the way out — this is the write side of the same thing.

Acceptance

create-project accepts an optional group id and the created project lands in that group.
Omitting it keeps today's behaviour (ungrouped), so nothing existing changes.
An invalid group id fails loudly rather than silently creating an ungrouped project — a silent fallback here reproduces the exact problem this fixes.

Unblocks

halfst/mpx-engine #120 (card↔effort pairing reconcile, Sync Spec §4.2), and retires the §4.2 caveat.

Filed from `halfst/mpx-engine` #120 / #137. ## What's needed `ticktick-create-project` should take an optional `group_id`, placing the new project directly into that sidebar folder group. ## Why `Sync Operating Spec` §4.2 currently records this as a permanent limitation and designs around it: > **MCP caveat:** `create_project` can't set a group — auto-created efforts land ungrouped; flag for manual drag. The engine's card↔effort reconcile is supposed to create a missing effort automatically when a Mission Control card has no paired sidebar project. Because the new project can't be grouped, every auto-creation currently produces an orphan in the sidebar plus a manual chore. It also forced a code path in the engine: `reconcile_registry` has an `unplaced` outcome purely to surface projects that exist but sit in no known folder group, because they can't be filed into a Registry section without a group. With this, that path becomes dead code for anything the sync creates. `list-projects` already returns `group_id` on read, so the field is understood on the way out — this is the write side of the same thing. ## Acceptance - [ ] `create-project` accepts an optional group id and the created project lands in that group. - [ ] Omitting it keeps today's behaviour (ungrouped), so nothing existing changes. - [ ] An invalid group id fails loudly rather than silently creating an ungrouped project — a silent fallback here reproduces the exact problem this fixes. ## Unblocks `halfst/mpx-engine` #120 (card↔effort pairing reconcile, Sync Spec §4.2), and retires the §4.2 caveat.