Feature Implementation

Systematic approach to implementing new features in the Rust memory system.

Purpose

Add new functionality following project conventions, maintaining code quality and test coverage.

Implementation Process

Phase 1: Planning

1. Understand Requirements

• What is the feature?
• Why is it needed?
• Who will use it?
• What are the acceptance criteria?

2. Design Approach

• How does it fit into existing architecture?
• What modules need changes?
• What new modules are needed?
• What are the data structures?
• What are the API signatures?

3. Check Constraints

• File size limit: ≤ 500 LOC per file
• Async/Tokio patterns for I/O
• Error handling with

  anyhow::Result

• Storage: Turso (durable) + redb (cache)

Phase 2: Implementation

1. Create Module Structure

# For new module
touch src/new_feature/mod.rs
touch src/new_feature/core.rs
touch src/new_feature/storage.rs

# Update src/lib.rs
# pub mod new_feature;

Example structure:

src/
├── new_feature/
│   ├── mod.rs          # Public API exports
│   ├── core.rs         # Core logic (<500 LOC)
│   ├── storage.rs      # Storage operations (<500 LOC)
│   └── types.rs        # Data structures (<500 LOC)

2. Define Types

// src/new_feature/types.rs
use serde::{Deserialize, Serialize};

/// Feature data structure
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct FeatureData {
    pub id: String,
    pub created_at: i64,
    pub data: serde_json::Value,
}

/// Configuration for feature
#[derive(Debug, Clone)]
pub struct FeatureConfig {
    pub enabled: bool,
    pub max_items: usize,
}

3. Implement Core Logic

// src/new_feature/core.rs
use anyhow::Result;

/// Main feature implementation
pub struct Feature {
    config: FeatureConfig,
}

impl Feature {
    /// Create new feature instance
    pub fn new(config: FeatureConfig) -> Self {
        Self { config }
    }

    /// Core feature operation
    pub async fn process(&self, input: FeatureData) -> Result<FeatureData> {
        // Validate input
        self.validate(&input)?;

        // Process
        let processed = self.process_internal(input).await?;

        // Store result
        self.store(&processed).await?;

        Ok(processed)
    }

    fn validate(&self, data: &FeatureData) -> Result<()> {
        // Validation logic
        Ok(())
    }

    async fn process_internal(&self, data: FeatureData) -> Result<FeatureData> {
        // Processing logic
        Ok(data)
    }

    async fn store(&self, data: &FeatureData) -> Result<()> {
        // Storage logic
        Ok(())
    }
}

4. Add Storage Layer

// src/new_feature/storage.rs
use super::types::FeatureData;
use anyhow::Result;

/// Turso storage for feature
pub struct FeatureStorage {
    turso: TursoClient,
}

impl FeatureStorage {
    pub async fn save(&self, data: &FeatureData) -> Result<()> {
        let sql = "INSERT OR REPLACE INTO feature_table (id, data, created_at) VALUES (?, ?, ?)";
        self.turso
            .execute(sql)
            .bind(&data.id)
            .bind(serde_json::to_string(&data.data)?)
            .bind(data.created_at)
            .await?;
        Ok(())
    }

    pub async fn get(&self, id: &str) -> Result<Option<FeatureData>> {
        let sql = "SELECT id, data, created_at FROM feature_table WHERE id = ?";
        let row = self.turso.query(sql).bind(id).await?;

        // Parse and return
        Ok(None) // Placeholder
    }
}

5. Implement Public API

// src/new_feature/mod.rs
mod core;
mod storage;
mod types;

pub use types::{FeatureConfig, FeatureData};
pub use core::Feature;

/// Convenience function for common use case
pub async fn quick_process(data: FeatureData) -> anyhow::Result<FeatureData> {
    let feature = Feature::new(FeatureConfig::default());
    feature.process(data).await
}

Phase 3: Testing

1. Unit Tests

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_feature_creation() {
        let config = FeatureConfig {
            enabled: true,
            max_items: 100,
        };
        let feature = Feature::new(config);
        assert!(feature.config.enabled);
    }

    #[test]
    fn test_validation() {
        let feature = Feature::new(FeatureConfig::default());
        let data = FeatureData {
            id: "test".to_string(),
            created_at: 0,
            data: serde_json::json!({}),
        };
        assert!(feature.validate(&data).is_ok());
    }

    #[tokio::test]
    async fn test_process() {
        let feature = Feature::new(FeatureConfig::default());
        let input = create_test_data();
        let result = feature.process(input).await;
        assert!(result.is_ok());
    }
}

2. Integration Tests

// tests/integration/feature_test.rs
use memory_core::new_feature::*;

#[tokio::test]
async fn test_end_to_end_feature() {
    // Setup
    let memory = create_test_memory().await;

    // Execute feature
    let data = FeatureData { /* ... */ };
    let result = memory.feature_operation(data).await;

    // Verify
    assert!(result.is_ok());

    // Check storage
    let stored = memory.get_feature_data("id").await.unwrap();
    assert_eq!(stored.id, "id");
}

Phase 4: Integration

1. Wire into Main API

// src/lib.rs
pub mod new_feature;

use new_feature::Feature;

pub struct SelfLearningMemory {
    // Existing fields...
    feature: Feature,
}

impl SelfLearningMemory {
    pub async fn feature_operation(&self, data: FeatureData) -> Result<FeatureData> {
        self.feature.process(data).await
    }
}

2. Update Database Schema

-- migrations/003_add_feature_table.sql
CREATE TABLE IF NOT EXISTS feature_table (
    id TEXT PRIMARY KEY,
    data TEXT NOT NULL,
    created_at INTEGER NOT NULL
);

CREATE INDEX idx_feature_created ON feature_table(created_at DESC);

3. Add Configuration

// src/config.rs
pub struct Config {
    // Existing config...
    pub feature_config: FeatureConfig,
}

Phase 5: Documentation

1. Code Documentation

/// Process feature data through the memory system.
///
/// This function takes raw feature data, validates it, processes it according
/// to learned patterns, and stores the result in both Turso and redb.
///
/// # Arguments
///
/// * `data` - The feature data to process
///
/// # Returns
///
/// Processed feature data with enriched information
///
/// # Errors
///
/// Returns error if:
/// - Data validation fails
/// - Storage operations fail
/// - Processing encounters unrecoverable error
///
/// # Example
///
/// ```no_run
/// use memory_core::new_feature::*;
///
/// #[tokio::main]
/// async fn main() -> anyhow::Result<()> {
///     let data = FeatureData {
///         id: "example".to_string(),
///         created_at: 1234567890,
///         data: serde_json::json!({"key": "value"}),
///     };
///
///     let result = quick_process(data).await?;
///     println!("Processed: {:?}", result);
///     Ok(())
/// }
/// ```
pub async fn feature_operation(&self, data: FeatureData) -> Result<FeatureData>

2. Update README

Add feature to main README.md:

## Features

- Episodic memory storage
- Pattern extraction and learning
- Context retrieval
- **NEW: Feature name** - Brief description

Phase 6: Quality Checks

# Format
cargo fmt

# Lint
cargo clippy --all -- -D warnings

# Build
cargo build --all

# Test
cargo test --all

# Documentation
cargo doc --no-deps

Phase 7: Commit

# Stage changes
git add src/new_feature/ tests/integration/feature_test.rs

# Commit with clear message
git commit -m "[feature] add new_feature module

- Implemented core Feature struct with process logic
- Added Turso storage layer with save/get operations
- Created comprehensive unit and integration tests
- Updated main API to expose feature_operation
- Added database migration for feature_table

Closes: #123
"

Best Practices

Code Organization

• One feature per module
• Split large modules (< 500 LOC per file)
• Clear separation: types, core logic, storage, API

Error Handling

// Good: Propagate errors
pub async fn operation(&self) -> Result<Data> {
    let data = self.fetch().await?;
    self.process(data).await?;
    Ok(data)
}

// Bad: Swallow errors
pub async fn operation(&self) -> Option<Data> {
    let data = self.fetch().await.ok()?;  // Error info lost
    Some(data)
}

Async Patterns

// Good: Concurrent operations
let (result1, result2) = tokio::join!(
    operation1(),
    operation2(),
);

// Bad: Sequential when could be concurrent
let result1 = operation1().await;
let result2 = operation2().await;

Testing

• Unit tests for each function
• Integration tests for workflows
• Test error cases
• Test edge cases (empty, max, invalid)

Documentation

• Public APIs must be documented
• Include examples for complex APIs
• Document errors and edge cases
• Keep docs up to date with code

Feature Checklist

• Requirements understood
• Design reviewed
• Module structure created
• Types defined
• Core logic implemented
• Storage layer added
• Public API exposed
• Unit tests written (>80% coverage)
• Integration tests added
• Documentation written
• Code formatted (

  cargo fmt

  )
• Lints pass (

  cargo clippy

  )
• All tests pass (

  cargo test --all

  )
• Build succeeds (

  cargo build --release

  )
• Committed with clear message
• PR created (if applicable)

Common Pitfalls

1. Forgetting

.await

// Wrong
let data = async_function();  // Returns Future, not Data

// Right
let data = async_function().await?;

2. Blocking in Async Context

// Wrong
async fn process() {
    std::thread::sleep(Duration::from_secs(1));  // Blocks executor!
}

// Right
async fn process() {
    tokio::time::sleep(Duration::from_secs(1)).await;
}

3. Not Testing Error Cases

#[tokio::test]
async fn test_error_handling() {
    let result = operation_with_invalid_input().await;
    assert!(result.is_err());
    assert!(matches!(result.unwrap_err(), Error::InvalidInput(_)));
}

4. Ignoring Performance

// Consider batch operations
for item in items {
    storage.save(item).await?;  // N database calls
}

// Better
storage.save_batch(items).await?;  // 1 database call

Integration with GitHub Release Best Practices

This skill integrates with the GitHub release best practices workflow for feature development and release management:

Release Preparation Integration

When implementing features for release:

1. Version Impact Assessment: Consult github-release-best-practices skill for semantic versioning implications
2. Changelog Planning: Consider Keep a Changelog format for feature documentation
3. Quality Gates: Ensure implementation meets release standards (>90% coverage, zero warnings)
4. Breaking Changes: Identify and document any breaking changes for migration guides

Coordination Workflows

• Pre-Implementation: Use github-release-best-practices for version planning
• Implementation: Follow feature-implement patterns while considering release requirements
• Testing: Coordinate with testing-qa for release validation
• Release Creation: Leverage github-release-best-practices agent for final release orchestration

Example Integration Pattern

## Feature Implementation → Release Workflow

1. **Assessment Phase**
   - github-release-best-practices: Analyze feature scope and version impact
   - feature-implement: Plan implementation with release considerations

2. **Implementation Phase**
   - feature-implement: Execute feature development
   - testing-qa: Ensure quality gates met
   - code-reviewer: Validate implementation standards

3. **Release Phase**
   - github-release-best-practices: Update changelog, create release notes
   - goap-agent: Coordinate final release creation

This integration ensures features are implemented with release readiness in mind, following 2025 GitHub release best practices for Rust workspaces.