Query tasks by tag #5

New issue

Closed

opened 2026-08-09 19:52:31 -05:00 by mcp-gateway · 0 comments

mcp-gateway commented

2026-08-09 19:52:31 -05:00

Member

Filed from halfst/mpx-engine #120.

What's needed

A way to list tasks carrying a given tag — either a tag filter on ticktick-list-tasks or a dedicated tool.

Why

Sync Operating Spec §11.2 defines the P1/P7 altitude-tag rotation as strip, then apply:

Each ceremony first removes its altitude tag from every task still carrying it, then applies it to the current period's tasks. The tag never accumulates.

"Every task still carrying it" is a tag query. Without one, §10 records the workaround as an accepted gap:

p1 + p7 tag rotation has no tag-query (§11.2) — carriers found by scanning each ceremony's window; acceptable by design.

Scanning the ceremony's window finds carriers inside that window. A task tagged p1 three weeks ago and never revisited sits outside it and keeps the tag forever, which is precisely the accumulation the strip step exists to prevent. The workaround is correct for the common case and silently wrong for the stale one.

One important detail — match on `name`, never `raw_name`

Whatever the query keys off, it must match the tag's display name, not its raw_name.

Sync Operating Spec §11 is emphatic, and this estate has live evidence:

Match on name, never raw_name — this is now more load-bearing, not less. Two of the five rebuilt tags were themselves renamed after creation and still report their birth names: p1 reports raw_name: top_3 and p7 reports raw_name: weekly_priorities. TickTick has never once rewritten a raw_name on rename.

RAIDQ A-24 found six of sixteen live tags carrying a stale birth name. A tag query that filters on raw_name will silently mis-target, and will mis-target differently each time the tags are rebuilt.

If both are exposed, document which one the filter uses.

Acceptance

Filter tasks by tag, matching on display name.
Documented behaviour for nested tags — the altitude tags live under an mpx parent, and it matters whether querying the parent returns children.
Documented whether completed tasks are included; the rotation's strip step needs to reach them or the tag survives on a closed task.

Unblocks

Exact rotate_altitude_tag in halfst/mpx-engine (Engine Spec §3 assigns rotation to the sync module, called by the P1/P7 ceremonies), and closes the §10 open item.

Filed from `halfst/mpx-engine` #120. ## What's needed A way to list tasks carrying a given tag — either a `tag` filter on `ticktick-list-tasks` or a dedicated tool. ## Why `Sync Operating Spec` §11.2 defines the P1/P7 altitude-tag rotation as **strip, then apply**: > Each ceremony first removes its altitude tag from every task still carrying it, then applies it to the current period's tasks. The tag never accumulates. "Every task still carrying it" is a tag query. Without one, §10 records the workaround as an accepted gap: > **`p1` + `p7` tag rotation has no tag-query (§11.2)** — carriers found by scanning each ceremony's window; acceptable by design. Scanning the ceremony's window finds carriers *inside that window*. A task tagged `p1` three weeks ago and never revisited sits outside it and keeps the tag forever, which is precisely the accumulation the strip step exists to prevent. The workaround is correct for the common case and silently wrong for the stale one. ## One important detail — match on `name`, never `raw_name` Whatever the query keys off, it must match the tag's **display name**, not its `raw_name`. `Sync Operating Spec` §11 is emphatic, and this estate has live evidence: > **Match on `name`, never `raw_name` — this is now more load-bearing, not less.** Two of the five rebuilt tags were themselves renamed after creation and still report their birth names: `p1` reports `raw_name: top_3` and `p7` reports `raw_name: weekly_priorities`. TickTick has never once rewritten a `raw_name` on rename. RAIDQ A-24 found six of sixteen live tags carrying a stale birth name. A tag query that filters on `raw_name` will silently mis-target, and will mis-target *differently* each time the tags are rebuilt. If both are exposed, document which one the filter uses. ## Acceptance - [ ] Filter tasks by tag, matching on display `name`. - [ ] Documented behaviour for nested tags — the altitude tags live under an `mpx` parent, and it matters whether querying the parent returns children. - [ ] Documented whether completed tasks are included; the rotation's strip step needs to reach them or the tag survives on a closed task. ## Unblocks Exact `rotate_altitude_tag` in `halfst/mpx-engine` (Engine Spec §3 assigns rotation to the `sync` module, called by the P1/P7 ceremonies), and closes the §10 open item.