refactor: align flag shorthands with GNU/POSIX CLI conventions

[BRO3886]

Summary

Several flag shorthands in rem either violate GNU/POSIX CLI conventions or are missing entirely. This makes the CLI less intuitive for experienced terminal users who expect standard shorthand letters.

Current flag inventory

Flags with shorthands

Flag	Short	Commands	Notes
--output	-o	global	OK — standard
--list	-l	most commands	OK — standard
--due	-d	add, update	OK
--priority	-p	add, update	OK
--notes	-n	add, update	OK
--url	-u	add, update	OK
--flagged	-f	add	Problem — -f universally means --force
--force	-y	delete, list-mgmt delete	Problem — -y typically means --yes, not --force
--search	-s	list	OK
--interactive	-i	mutation commands	OK
--count	-c	list-mgmt lists	OK

Flags missing shorthands

Flag	Commands	Suggested short	Convention source
--tags	add	-t	docker, git tag
--remind-me	add, update	-r	mnemonic
--repeat	add, update	(none — no clear convention)
--silent	add	(none — situational)
--name	update	-t (or rename to --title)	see note below
--add-tags	update	(none — compound flag)
--remove-tags	update	(none — compound flag)
--dry-run	import	-n	make, rsync, ansible
--days	upcoming	-n	head, tail, git log
--format	export	-f (free on export)	common
--output-file	export	-O	curl, wget
--agent	skills	-a	mnemonic
--incomplete	list, search, export	(none — filter toggle)
--completed	list	(none — filter toggle)
--due-before	list	(none — compound flag)
--due-after	list	(none — compound flag)

Breaking changes (high priority)

1. -f should mean --force, not --flagged

Nearly every CLI in existence uses -f for --force (rm, git, docker, kubectl). Currently -f is bound to --flagged on rem add, which forced --force onto -y on delete commands. This is the root cause of the convention violation.

Proposed fix:

• Remove -f from --flagged on add → use -F (capital) for --flagged, or no shorthand
• Add -f to --force on delete and list-mgmt delete
• Keep --yes/-y as an alias for --force (this pairing is conventional — apt, yum, pacman all use -y for --yes)

2. --name on update vs positional title on add

rem add "My Title" uses a positional arg for the title, but rem update <id> --name "New Title" uses --name. Consider renaming --name to --title for consistency with the domain model (go-eventkit uses Title, not Name). This would also free up a natural -t shorthand.

3. --flagged on update is a string type

--flagged on add/list/complete/delete is a bool, but on update it's a string accepting true/false. This exists to allow clearing the flag, but rem unflag <id> already does that. Consider making it a bool on update too, with rem unflag as the clearing mechanism.

New shorthands (non-breaking)

These are additive — no existing behavior changes:

Change	Priority
-t for --tags (add)	High
-r for --remind-me (add, update)	Medium
-n for --dry-run (import)	Medium
-O for --output-file (export)	Medium
-f for --format (export)	Medium
-a for --agent (skills)	Low

Migration / breaking change strategy

The -f swap is a breaking change for anyone using rem add -f. Options:

1. Just swap it — rem is pre-1.0, breaking changes are expected
2. Deprecation period — accept both for one release with a warning, then remove
3. Announce in release notes — document the change prominently

Recommend option 1 since rem is pre-1.0 and the current behavior violates universal CLI conventions.

References

• GNU Coding Standards — Command-Line Interfaces
• POSIX Utility Conventions
• CLI Guidelines (clig.dev)