refine cursor rules for pagination

.cursor/rules/README.mdc

@@ -53,6 +53,8 @@ Secondary Repos:
 
 - endorser-mobile is the previous native app to talk to the Endorser server -- very powerful but harder to use
 
+### Hosting
+
 These repos are hosted by GitHub: endorser-ch, endorser-mobile, lives-of-gifts uport-demo, endorser-docs, time-safari-web
 
 The remaining repos are hosted by gitea.anomalistdesign.com

.cursor/rules/endorser-service.mdc

@@ -100,26 +100,13 @@ const result = {
 
 When creating new paginated endpoints:
 
-- [ ] Use `beforeId`/`afterId` query parameters in routes
+- Use `beforeId`/`afterId` query parameters in routes
-- [ ] Pass these parameters to database methods as `afterIdInput`/`beforeIdInput`
+- Pass these parameters to database methods as `afterIdInput`/`beforeIdInput`
-- [ ] Use JWT ID comparisons (`jwtId > ?`, `jwtId < ?`) in SQL
+- Use JWT ID comparisons (`jwtId > ?`, `jwtId < ?`) in SQL
-- [ ] Return `{ data: [], hitLimit: boolean }` response format
+- Include `DEFAULT_LIMIT` constant in SQL for consistent limits
-- [ ] Document parameters with standard JSDoc format
+- Return `{ data: [], hitLimit: boolean }` response format
-- [ ] Never use `limit`, `offset`, `page`, or similar parameters
+- Document parameters with standard JSDoc format
-
+- Never use `limit`, `offset`, `page`, or similar parameters
-## Error Prevention
-
-**Red Flags** - These patterns should be avoided:
-- Any mention of `limit` or `offset` in parameter names
-- `LIMIT ? OFFSET ?` in SQL queries
-- `parseInt(req.query.limit)` in route handlers
-- Response objects with `page`, `totalPages`, `totalCount` fields
-
-**Green Flags** - These patterns should be used:
-- `beforeId`/`afterId` parameter naming
-- `jwtId > ?` and `jwtId < ?` SQL conditions
-- `hitLimit` boolean in responses
-- `DEFAULT_LIMIT` constant for consistent limits
 
 # Database Migration Documentation
 
@@ -181,7 +168,7 @@ async function hideDidsAndAddLinksToNetworkInDataKey(requesterDid, input, search
 
 ### Critical searchTerms Parameter
 
-**SECURITY REQUIREMENT**: The `searchTerms` parameter MUST contain any user-provided query data that might include DIDs or parts of DIDs.
+**SECURITY REQUIREMENT**: The `searchTerms` parameter MUST contain all user-provided query data (since it might include DIDs or parts of DIDs).
 
 #### Why searchTerms is Required
 
@@ -234,8 +221,9 @@ Always include search terms when:
 
 ### Security Checklist
 
-When implementing endpoints that use `hideDidsAndAddLinksToNetwork`:
+When implementing endpoints, always consider usage of `hideDidsAndAddLinksToNetwork`:
 
+- [ ] Use it for almost every endpoint, and exceptions should be vetted and documented
 - [ ] Identify all user-provided query parameters
 - [ ] Include any parameter that could contain DIDs in `searchTerms`
 - [ ] Include any text search parameters in `searchTerms`