feat: implement pagination for feature queries in API (#31)

Author: HideBa

.cursor/rules/general.mdc

@@ -1,6 +1,6 @@
 ---
 description: General rules about the project and coding guidelines
-globs: 
+globs:
 alwaysApply: true
 ---
 # Important Rules for LLM
@@ -21,9 +21,10 @@ I am a specialized software engineer with a distinct characteristic: my memory r
 
 ## Memory Bank Structure
 
-All files are stored under [productContext.md](mdc:.cursor/rules/memory/productContext.md), [progress.md](mdc:.cursor/rules/memory/progress.md), [specification.md](mdc:.cursor/rules/memory/specification.md) and `.cursor/memory/*`. The memory bank consists of mandatory core files and optional context files, all formatted in Markdown. 
+All files are stored under [productContext.md](mdc:.cursor/rules/memory/productContext.md), [progress.md](mdc:.cursor/rules/memory/progress.md), [specification.md](mdc:.cursor/rules/memory/specification.md) and `.cursor/memory/*`. The memory bank consists of mandatory core files and optional context files, all formatted in Markdown.
 
 ### Core Files (Mandatory)
+
 1. **`productContext.md`** [productContext.md](mdc:.cursor/rules/memory/productContext.md)
    - Explains the purpose of the project.
    - Identifies the problem it solves.
@@ -39,6 +40,7 @@ All files are stored under [productContext.md](mdc:.cursor/rules/memory/productC
 ### Additional Context Files
 
 Additional files and folders can be created inside `memory/rules/memory*` if they aid in organization:
+
 - Documentation for complex features.
 - Integration specifications.
 - API documentation.
@@ -76,6 +78,7 @@ flowchart TD
 ## Updating Documentation
 
 Memory bank updates occur under the following conditions:
+
 1. When a new project pattern is discovered.
 2. After implementing a significant change.
 3. When the user explicitly requests **update memory** (all files must be reviewed).
@@ -122,6 +125,7 @@ flowchart TD
 ```
 
 ### Key Information to Record
+
 - Critical implementation paths.
 - User preferences and workflows.
 - Project-specific patterns.
@@ -135,9 +139,11 @@ flowchart TD
 
 - Memory is finite, so large files should not be loaded unnecessarily.
 - Before reading `*.json` or `*.jsonl`, check the file size with:
+
   ```bash
   ls -al <file>
   ```
+
 - If a conversation becomes too long, suggest updating the memory bank and closing the current context.
 
 ---
@@ -147,34 +153,40 @@ flowchart TD
 ## Commit Best Practices
 
 1. **Review Changes**
+
    ```bash
    git status
    git diff
    git log
    ```
+
 2. **Analyze Changes**
    - Identify modified or added files.
    - Understand the nature of changes (new feature, bug fix, refactoring, etc.).
    - Evaluate the impact on the project.
    - Ensure no sensitive information is exposed.
 3. **Create Meaningful Commit Messages**
+
    ```bash
    git commit -m "fix: Resolve issue with authentication timeout"
    ```
 
 ## Pull Request Best Practices
 
 1. **Review Branch Status**
+
    ```bash
    git status
    git diff main...HEAD
    git log
    ```
+
 2. **Analyze Changes**
    - Review all commits made since branching off `main`.
    - Assess change scope and impact.
    - Ensure no sensitive data is committed.
 3. **Create a Pull Request**
+
    ```bash
    gh pr create --title "feat: Improve Rust error handling" --body "Improved error handling with Result<T, E>."
    ```
@@ -183,10 +195,9 @@ flowchart TD
 
 # Local MCP
 
-## `readUrl`
+## `serena`
 
-- Reads an article and extracts the main content.
-- If the user asks to research a topic that is unknown, request a URL.
+- `serena` is a tool that can be used to get overview of the code base.
 
 ---
 
@@ -199,11 +210,7 @@ flowchart TD
 - Prefer functions over structs when internal state is unnecessary.
 - Use adapters to abstract dependencies and facilitate testing.
 
-## Error Handling
-
-- Use `Result<T, E>` for error management.
-- Define specific error types.
-- Ensure exhaustive error handling.
+## Error
 
 ## Implementation Patterns
 

.cursor/rules/memory/tdd-rust-guidelines.md

@@ -6,6 +6,7 @@ alwaysApply: true
 # Rust Coding Guidelines for Library Development
 
 ## General Principles
+
 - Write **idiomatic Rust** code that is clear, efficient, and maintainable.
 - Prioritize **safety, performance, and modularity**.
 - Follow **Rust’s naming conventions**:
@@ -20,111 +21,16 @@ alwaysApply: true
 
 ---
 
-## Project Structure
-- The Rust codebase consists of **multiple crates** and their modules.
-- Organize the library using Rust’s standard `src/lib.rs` format.
-- Place implementation details inside separate modules within `src/`.
-- Keep `lib.rs` minimal, exposing only the public API.
-- Use `mod.rs` for submodules when necessary.
-- Follow **Cargo best practices** for managing dependencies and features.
-
-### Example Folder Structure
-```
-.
-├── bst
-│   └── src
-│       ├── byte_serializable.rs
-│       ├── error.rs
-│       ├── lib.rs
-│       ├── query
-│       │   ├── common.rs
-│       │   ├── fs.rs
-│       │   ├── http.rs
-│       │   ├── mod.rs
-│       │   └── stream.rs
-│       └── sorted_index.rs
-├── btree
-│   └── src
-│       ├── entry.rs
-│       ├── errors.rs
-│       ├── http.rs
-│       ├── key.rs
-│       ├── lib.rs
-│       ├── node.rs
-│       ├── query.rs
-│       ├── storage.rs
-│       ├── stream.rs
-│       └── tree.rs
-├── cli
-│   └── src
-│       └── main.rs
-├── fcb_core
-│   ├── benches
-│   │   ├── read.rs
-│   │   ├── read_attr.rs
-│   │   └── read_profile.rs
-│   ├── benchmark_data
-│   │   └── attribute
-│   ├── scripts
-│   └── src
-│       ├── bin
-│       │   ├── read.rs
-│       │   ├── read_attr.rs
-│       │   ├── read_attr_stream.rs
-│       │   ├── read_cj.rs
-│       │   └── write.rs
-│       ├── cj_utils.rs
-│       ├── cjerror.rs
-│       ├── const_vars.rs
-│       ├── error.rs
-│       ├── fb
-│       │   ├── feature_generated.rs
-│       │   ├── header_generated.rs
-│       │   └── mod.rs
-│       ├── http_reader
-│       │   ├── mock_http_range_client.rs
-│       │   └── mod.rs
-│       ├── lib.rs
-│       ├── reader
-│       │   ├── attr_query.rs
-│       │   ├── city_buffer.rs
-│       │   ├── deserializer.rs
-│       │   ├── geom_decoder.rs
-│       │   └── mod.rs
-│       └── writer
-│           ├── attr_index.rs
-│           ├── attribute.rs
-│           ├── error.rs
-│           ├── feature_writer.rs
-│           ├── geom_encoder.rs
-│           ├── header_writer.rs
-│           ├── mod.rs
-│           └── serializer.rs
-├── packed_rtree
-│   └── src
-│       ├── error.rs
-│       └── lib.rs
-├── src
-│   └── lib.rs
-├── temp
-└── wasm
-    ├── pkg
-    └── src
-        ├── gloo_client.rs
-        └── lib.rs
-
-```
-
----
-
 ## Error Handling
+
 - Use `thiserror` to make custom error for package-level errors. You shouldn't use `anyhow` unless I explictly approve you to do that.
 - Avoid panics in library code; return errors instead.
 - Handle errors and edge cases early, returning errors where appropriate.
 
 ---
 
 ## Performance Optimization
+
 - Use **iterators instead of loops** for better performance and readability.
 - Minimize memory allocations by using **borrowed references (`&str`, `&[u8]`)** where possible.
 - Optimize for **human readability** while maintaining machine efficiency.
@@ -133,6 +39,7 @@ alwaysApply: true
 ---
 
 ## Async Programming
+
 - Use `tokio` as the async runtime.
 - Prefer **channels over mutexes** where applicable.
 - Implement **structured concurrency** using `tokio::select!`.
@@ -142,33 +49,40 @@ alwaysApply: true
 ---
 
 ## API Design
+
 - Follow **Rust’s API guidelines** for public interfaces.
 - Use **builder patterns** for complex configurations.
 
 ---
 
 ## Testing
+
 - Write **unit tests** with `#[cfg(test)]`.
 - Use **integration tests** for public APIs in the `tests/` directory.
 - Mock external dependencies where necessary.
 - Use `tokio::test` for as
 mentation
 - Write **Rustdoc** comments for public functions and structs.
 - Include examples in   preview document
+
 ---
 
 ## Dependency Management
+
 - Use `cargo-audit` to che**minimal and up-to-date**.
+- Add crates to workspace's `Cargo.toml` file. Don't add them to individual crates' `Cargo.toml` files.
 
 ---
 
 ## Logging and Debugging
+
 - Use `tracing` for structured logging.
 - Enable debug assertions wit_assert!()`.
 
 ---
 
 ## Final Notes
+
 - Follow **Rust's idiomatic coding practices**.
 - Endut e, safety, and maintainability**.
 - Maintain a **black-and-white, pixelated/nerdy ltao  will remain robust, efficient, and maintainable across its m crates and modules. 🚀