feat: add hashtag tag support

[klukacin]

Summary

• Adds hashtag-based tag parsing from trailing #tags in reminder titles
• Adds remindctl tags, add --tag, edit --tag/--remove-tag/--clear-tags, and show --tag
• Includes tags and titleWithoutTags in JSON output while preserving v0.2.0 metadata fields
• Keeps v0.2.0 alarm, location, recurrence, all-day date, and open filter support

Test Plan

• swift test
• Manual CLI help check for root/add/edit/show tag options

Notes

This ports the previous tag-support work from #35 onto current main / v0.2.0-era commands and adds regression tests.

[Carecovisk]

This feature would be great!

[clawsweeper]

Codex review: needs real behavior proof before merge.

Latest ClawSweeper review: 2026-05-24 08:44 UTC / May 24, 2026, 4:44 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Summary
The PR adds trailing-hashtag parsing, a tags command, tag flags on add/edit/show, tag-aware JSON output, and focused tag helper tests.

Reproducibility: not applicable. this is a feature PR rather than a reported current-main bug. Source inspection confirms current main has no tag command or tag fields, so the open question is product direction.

PR rating
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🧂 unranked krab
Summary: Missing real behavior proof plus a P1 product-fit blocker make this PR not quality-ready for merge.

Rank-up moves:

• Ask maintainers whether to close this as a repeat of the rejected title-hashtag design or rescope it to plain-text notes-prefix metadata.
• If maintainers approve a rescope, add redacted terminal output or a recording showing the real add/edit/show/tags flow against Reminders.

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Real behavior proof
Needs real behavior proof before merge: The PR body lists swift test and a manual help check only; it needs redacted terminal output, logs, a screenshot, or a recording showing the real add/edit/show/tags flow before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• Merging this would create first-class CLI tag semantics by appending and parsing title hashtags despite current docs and a linked collaborator decision saying native Reminders tags and smart lists are outside the EventKit-backed CLI boundary.
• Users could reasonably mistake --tag for native Reminders tag or Smart List support, while the implementation actually mutates reminder titles as remindctl-specific metadata.
• The PR body lists tests and a help check only, so the real add/edit/show/tags flow against Reminders is still unproven.

Maintainer options:

1. Keep title-hashtag support out (recommended)
   Close or hold this PR unless maintainers explicitly reverse the prior decision and accept title hashtags as a supported remindctl metadata contract.
2. Rescope to notes-prefix metadata
   Replace the native-sounding tag surface with a clearly named notes-prefix parser/filter and update docs/tests around plain-text metadata semantics.
3. Accept the semantic change deliberately
   If maintainers want title hashtags anyway, require explicit docs, compatibility notes, and redacted real behavior proof before merge.

Next step before merge
Needs maintainer judgment on whether to reverse the prior no-title-hashtag decision or request a notes-prefix rescope; automation should not choose the metadata contract.

Security
Cleared: The diff does not touch CI, dependencies, secrets, packaging, downloaded artifacts, or other supply-chain execution paths.

Review findings

• [P1] Do not reintroduce title hashtags as tag support — Sources/remindctl/Commands/AddCommand.swift:40-45

Review details

Best possible solution:

Keep the current EventKit boundary; if maintainers want tag-like metadata, pursue a separately named notes-prefix parser/filter with docs, tests, and real CLI proof.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this is a feature PR rather than a reported current-main bug. Source inspection confirms current main has no tag command or tag fields, so the open question is product direction.

Is this the best way to solve the issue?

No; this ports the title-hashtag design already rejected in #35 and conflicts with the documented EventKit boundary. A safer direction is a clearly scoped notes-prefix metadata parser if maintainers want non-native tag-like filtering.

Label justifications:

• P2: This is a normal user-facing feature PR with limited blast radius, but it conflicts with a recent product-boundary decision.
• merge-risk: 🚨 compatibility: Merging would introduce a new tag contract that mutates reminder titles and may be confused with native Reminders tags despite current docs saying those are unsupported.
• rating: 🧂 unranked krab: Current PR rating is 🧂 unranked krab because proof is 🧂 unranked krab, patch quality is 🧂 unranked krab, and Missing real behavior proof plus a P1 product-fit blocker make this PR not quality-ready for merge.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists swift test and a manual help check only; it needs redacted terminal output, logs, a screenshot, or a recording showing the real add/edit/show/tags flow before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Full review comments:

• [P1] Do not reintroduce title hashtags as tag support — Sources/remindctl/Commands/AddCommand.swift:40-45
  Adding this --tag surface advertises native-sounding tag support, but the linked decision in feat: add tags (hashtag) support #35 rejected title hashtags because they are remindctl-specific title text, not native Reminders tags or Smart List metadata. Remove this surface or rescope it as clearly named plain-text metadata before merge.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.93

What I checked:

• PR diff adds title-hashtag tag surface: The diff adds --tag to add, parses tags from titles, merges them, and writes the composed hashtag title into the reminder draft. (Sources/remindctl/Commands/AddCommand.swift:40, 0d6f02dede4b)
• Current docs define EventKit boundary: Current main says remindctl intentionally sticks to public EventKit APIs and lists native Reminders tags and smart lists as not exposed today. (README.md:220, 883ae257911e)
• Current command surface has no tag command: Current main registers show, list, add, edit, complete, delete, status, and authorize only; rg also found no tag command, --tag, titleWithoutTags, --remove-tag, or --clear-tags implementation. (Sources/remindctl/CommandRouter.swift:13, 883ae257911e)
• Related feature request was closed as not planned: A collaborator closed Feature Request - Support Tags and Smart Lists #18 after rechecking SDK headers, saying EventKit exposes no public tag or smart-list API and title hashtags would misrepresent what the CLI can modify.
• Earlier matching PR was closed unmerged: feat: add tags (hashtag) support #35 proposed the same title-hashtag design and was closed unmerged with guidance that a notes-prefix helper should be separate and clearly named as plain-text metadata.
• Latest release keeps the same boundary: Release v0.2.0 points at 1aff715 and includes the EventKit limits docs and command router without tag support, so the requested feature is not already shipped. (README.md:220, 1aff71567c38)

Likely related people:

• steipete: He authored the current EventKit boundary on main, recently touched adjacent command behavior, and closed the related issue and earlier title-hashtag PR with the product-boundary decision. (role: collaborator decision author and recent area contributor; confidence: high; commits: 1aff71567c38, 883ae257911e; files: README.md, Sources/RemindCore/Models.swift, Sources/remindctl/CommandRouter.swift)
• Wenyou Yi: He added skill guidance that tells agents not to use remindctl for native Reminders tags and smart lists, matching the same product boundary. (role: adjacent skill docs contributor; confidence: medium; commits: f3cd4eb68377; files: SKILL.md)
• PeterRosdahl: He authored the earlier title-hashtag implementation that this PR ports forward, so his work explains the branch provenance even though it is not current-main behavior. (role: prior unmerged implementation author; confidence: medium; commits: 14884afd76c3; files: Sources/RemindCore/Models.swift, Sources/remindctl/Commands/AddCommand.swift, Sources/remindctl/Commands/TagsCommand.swift)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 883ae257911e.

[clawsweeper]

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

Where did the egg go?

• The egg game starts only after the PR passes the real-behavior proof check.
• Before that, no creature or rarity is rolled. The treat waits for real proof.
• This is still just collectible flavor: proof affects review readiness, not creature quality.