doc: add some specific cursor rules for the Endorser Service, and enhance the emojis checklist

progress/TASK-emojis.md

@@ -7,10 +7,10 @@ Allow people to attach an emoji onto a record. The main entity to which emojis w
 
 ### 1. Data Structure Design
 **Emoji Claim Structure:**
-- **Context**: `"@context": "https://endorser.ch"`
+- **Context**: Optional, with default of `"@context": "https://endorser.ch"`
 - **Type**: `"Emoji"` 
 - **Text**: Contains one emoji - e.g., `"👍"`, `"❤️"`, or `"🚀"`
-- **Parent Item**: Object with `lastClaimId` field containing the handleId of the target action (e.g., GiveAction)
+- **ParentItem**: Object with `lastClaimId` field containing the handleId of the target action (e.g., GiveAction)
 
 - Why not multiple emojis (eg. to optimize bandwidth & storage when using many)?
   Because there's a possibility of removing an emoji, and then the communication and logic (on both client & server) for determining which is off and which is on becomes more complicated. It's also not a very typical action: people usually attach one at a time. It's possible, so it's an optimization worth considering someday.
@@ -56,6 +56,9 @@ Allow people to attach an emoji onto a record. The main entity to which emojis w
 - Any authenticated user can add emojis to any public GiveAction
 - Users can retrieve all emoji taggers on a particular GiveAction, though DIDs are subject to visibility constraints
 
+**Test**
+- [ ] Write tests for each case on the back end (multiple emojis, removal, etc) in a new test file
+
 ### 5. Client-Side
 **Add to UI**
 - [ ] Add the button for adding emojis, and a click sends it
@@ -84,7 +87,6 @@ export interface EmojiSummaryRecord {
 - [ ] Add `emojiCount` field (map of emoji to count) to `GiveSummaryRecord` interface
 
 ### 6. Test
-- [ ] Write tests for each case on the back end (multiple emojis, removal, etc)
 - [ ] Write tests for the front end
 
 ## Implementation Notes