@hybridlabor-api/bdb-hardware-pcb 0.1.0

package/mcp_servers/openscad-mcp-server/legacy/old/test_sam2_segmentation.py

@@ -0,0 +1,96 @@
+import os
+import sys
+import logging
+import argparse
+from pathlib import Path
+from typing import Dict, Any, List, Optional, Tuple
+
+# Configure logging
+logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(name)s - %(levelname)s - %(message)s')
+logger = logging.getLogger(__name__)
+
+# Add project root to path
+sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
+
+# Import SAM2 segmenter and config
+from src.ai.sam_segmentation import SAMSegmenter
+from src.config import SAM2_CHECKPOINT_PATH, SAM2_MODEL_TYPE, SAM2_USE_GPU, MASKS_DIR
+
+def test_sam2_segmentation(image_path: str, output_dir: Optional[str] = None, use_auto_points: bool = True):
+    """
+    Test SAM2 segmentation on an image.
+    
+    Args:
+        image_path: Path to the input image
+        output_dir: Directory to save segmentation results (default: config.MASKS_DIR)
+        use_auto_points: Whether to use automatic point generation
+    """
+    # Validate image path
+    if not os.path.exists(image_path):
+        logger.error(f"Image not found: {image_path}")
+        return
+    
+    # Use default output directory if not provided
+    if not output_dir:
+        output_dir = os.path.join(MASKS_DIR, Path(image_path).stem)
+    
+    # Create output directory
+    os.makedirs(output_dir, exist_ok=True)
+    
+    logger.info(f"Testing SAM2 segmentation on image: {image_path}")
+    logger.info(f"Model type: {SAM2_MODEL_TYPE}")
+    logger.info(f"Checkpoint path: {SAM2_CHECKPOINT_PATH}")
+    logger.info(f"Using GPU: {SAM2_USE_GPU}")
+    
+    try:
+        # Initialize SAM2 segmenter
+        logger.info("Initializing SAM2 segmenter...")
+        sam_segmenter = SAMSegmenter(
+            model_type=SAM2_MODEL_TYPE,
+            checkpoint_path=SAM2_CHECKPOINT_PATH,
+            use_gpu=SAM2_USE_GPU,
+            output_dir=output_dir
+        )
+        
+        # Perform segmentation
+        if use_auto_points:
+            logger.info("Using automatic point generation")
+            result = sam_segmenter.segment_with_auto_points(image_path)
+        else:
+            # Use center point of the image for manual point
+            logger.info("Using manual center point")
+            import cv2
+            image = cv2.imread(image_path)
+            h, w = image.shape[:2]
+            center_point = (w // 2, h // 2)
+            result = sam_segmenter.segment_image(image_path, points=[center_point])
+        
+        # Print results
+        logger.info(f"Segmentation completed with {result.get('num_masks', 0)} masks")
+        
+        if result.get('mask_paths'):
+            logger.info(f"Mask paths: {result.get('mask_paths')}")
+        
+        return result
+    
+    except Exception as e:
+        logger.error(f"Error in SAM2 segmentation: {str(e)}")
+        import traceback
+        traceback.print_exc()
+        return None
+
+if __name__ == "__main__":
+    # Parse command line arguments
+    parser = argparse.ArgumentParser(description="Test SAM2 segmentation")
+    parser.add_argument("image_path", help="Path to the input image")
+    parser.add_argument("--output-dir", help="Directory to save segmentation results")
+    parser.add_argument("--manual-points", action="store_true", help="Use manual center point instead of auto points")
+    
+    args = parser.parse_args()
+    
+    # Run test
+    test_sam2_segmentation(
+        args.image_path,
+        args.output_dir,
+        not args.manual_points
+    )

package/mcp_servers/openscad-mcp-server/legacy/requirements.txt

@@ -0,0 +1,57 @@
+# Core dependencies
+fastapi>=0.95.0
+uvicorn>=0.21.0
+pydantic>=2.0.0
+python-multipart>=0.0.6
+
+# MCP SDK
+git+https://github.com/modelcontextprotocol/python-sdk.git
+
+# Image processing
+pillow>=9.5.0
+opencv-python>=4.7.0
+
+# HTTP client
+requests>=2.28.0
+httpx>=0.24.0
+
+# Utilities
+python-dotenv>=1.0.0
+pyyaml>=6.0
+jinja2>=3.1.2
+numpy>=1.24.0
+uuid>=1.30.0
+tqdm>=4.65.0
+
+# Image Generation - Venice.ai API (optional)
+# (using existing requests and python-dotenv)
+
+# Image Generation - Google Gemini API
+google-generativeai>=0.3.0
+
+# Network and Service Discovery
+zeroconf>=0.39.0
+aiohttp>=3.8.4
+
+# 3D Reconstruction - CUDA Multi-View Stereo
+open3d>=0.17.0
+trimesh>=3.21.0
+pyrender>=0.1.45
+
+# Remote Processing
+fastapi-utils>=0.2.1
+python-jose>=3.3.0  # For JWT authentication
+aiofiles>=23.1.0
+
+# For development
+pytest>=7.3.1
+black>=23.3.0
+isort>=5.12.0
+pytest-asyncio>=0.21.0
+
+# Deprecated dependencies (kept for reference)
+# segment-anything-2>=1.0
+# torch>=2.0.0
+# torchvision>=0.15.0
+# pytorch3d>=0.7.4
+# ninja>=1.11.0

package/mcp_servers/openscad-mcp-server/legacy/rtfmd/README.md

@@ -0,0 +1,39 @@
+# Reasoning Trace Framework for OpenSCAD MCP Server
+
+This directory contains the Reasoning Trace Framework (RTF) documentation for the OpenSCAD MCP Server project. The RTF provides insight into the design decisions, mental models, and reasoning processes behind the implementation.
+
+## Directory Structure
+
+- `/rtfmd/files/` - Shadow file system mirroring the actual source code structure
+  - Contains `.md` files with the same names as their corresponding source files
+  - Each file documents the reasoning behind the implementation
+
+- `/rtfmd/knowledge/` - Domain knowledge documentation
+  - `/openscad/` - Knowledge about OpenSCAD and 3D modeling
+  - `/ai/` - Knowledge about AI and natural language processing
+  - `/nlp/` - Knowledge about natural language parameter extraction
+
+- `/rtfmd/decisions/` - Architectural decision records
+  - Documents major design decisions and their rationales
+
+## How to Use This Documentation
+
+1. Start with the `/rtfmd/files/src/main.py.md` file to understand the overall architecture
+2. Explore specific components through their corresponding `.md` files
+3. Refer to the knowledge directory for domain-specific information
+4. Review the decisions directory for major architectural decisions
+
+## Tags Used
+
+- `<metadata>` - File metadata including author, timestamp, version, etc.
+- `<exploration>` - Documents the exploration process and alternatives considered
+- `<mental-model>` - Explains the mental model used in the implementation
+- `<pattern-recognition>` - Identifies design patterns used
+- `<trade-off>` - Documents trade-offs considered and choices made
+- `<domain-knowledge>` - References to domain knowledge required
+- `<technical-debt>` - Acknowledges technical debt and future improvements
+- `<knowledge-refs>` - References to related knowledge documents
+
+## Contributing
+
+When modifying the codebase, please update the corresponding RTF documentation to reflect your reasoning and design decisions.

package/mcp_servers/openscad-mcp-server/legacy/rtfmd/decisions/ai-driven-code-generation.md

@@ -0,0 +1,122 @@
+# AI-Driven Code Generation for OpenSCAD
+
+<metadata>
+  author: devin-ai-integration
+  timestamp: 2025-03-21T01:30:00Z
+  version: 1.0.0
+  tags: [ai, code-generation, openscad, architecture-decision]
+</metadata>
+
+## Decision Context
+
+The OpenSCAD MCP Server requires a mechanism to translate natural language descriptions into valid OpenSCAD code. This architectural decision record documents the approach chosen for implementing AI-driven code generation.
+
+## Options Considered
+
+### Option 1: Template-Based Approach
+
+A simple approach using predefined templates with parameter substitution.
+
+**Pros:**
+- Simple implementation
+- Predictable output
+- Low computational requirements
+
+**Cons:**
+- Limited flexibility
+- Cannot handle complex or novel descriptions
+- Requires manual creation of templates for each shape type
+
+### Option 2: Full Machine Learning Approach
+
+Using embeddings and neural networks to generate OpenSCAD code directly.
+
+**Pros:**
+- Highly flexible
+- Can handle novel descriptions
+- Potential for more natural interaction
+
+**Cons:**
+- High computational requirements
+- Requires training data
+- Less predictable output
+- Harder to debug and maintain
+
+### Option 3: Hybrid Pattern Matching with Contextual Rules
+
+Combining pattern matching for parameter extraction with rule-based code generation.
+
+**Pros:**
+- Good balance of flexibility and predictability
+- Moderate computational requirements
+- Easier to debug and maintain
+- Can be extended with more sophisticated ML in the future
+
+**Cons:**
+- More complex than pure template approach
+- Less flexible than full ML approach
+- Requires careful design of rules and patterns
+
+## Decision
+
+**Chosen Option: Option 3 - Hybrid Pattern Matching with Contextual Rules**
+
+The hybrid approach was selected because it provides a good balance of flexibility, maintainability, and computational efficiency. It allows for handling a wide range of natural language descriptions while maintaining predictable output and being easier to debug than a full ML approach.
+
+## Implementation Details
+
+The implementation consists of two main components:
+
+1. **Parameter Extractor**: Uses regex patterns and contextual rules to extract parameters from natural language descriptions.
+
+2. **Code Generator**: Translates extracted parameters into OpenSCAD code using a combination of templates and programmatic generation.
+
+The `AIService` class provides the bridge between these components, handling the overall flow from natural language to code.
+
+```python
+class AIService:
+    def __init__(self, templates_dir, model_config=None):
+        self.templates_dir = templates_dir
+        self.model_config = model_config or {}
+        self.templates = self._load_templates()
+    
+    def generate_openscad_code(self, context):
+        description = context.get("description", "")
+        parameters = context.get("parameters", {})
+        
+        # Parse the description to identify key components
+        components = self._parse_description(description)
+        
+        # Generate code based on identified components
+        code = self._generate_code_from_components(components, parameters)
+        
+        return code
+```
+
+## Consequences
+
+### Positive
+
+- More flexible code generation than a pure template approach
+- Better maintainability than a full ML approach
+- Lower computational requirements
+- Easier to debug and extend
+- Can handle a wide range of natural language descriptions
+
+### Negative
+
+- More complex implementation than a pure template approach
+- Requires careful design of patterns and rules
+- May still struggle with very complex or ambiguous descriptions
+
+### Neutral
+
+- Will require ongoing maintenance as new shape types and features are added
+- May need to be extended with more sophisticated ML techniques in the future
+
+## Follow-up Actions
+
+- Implement unit tests for the AI service
+- Create a comprehensive set of test cases for different description types
+- Document the pattern matching rules and code generation logic
+- Consider adding a feedback mechanism to improve the system over time

package/mcp_servers/openscad-mcp-server/legacy/rtfmd/decisions/export-formats.md

@@ -0,0 +1,76 @@
+# Decision: Export Format Selection
+
+<metadata>
+  author: devin-ai-integration
+  timestamp: 2025-03-21T12:00:00Z
+  version: 1.0.0
+  tags: [export-formats, 3d-printing, decision, prusa, bambu]
+</metadata>
+
+## Context
+
+The OpenSCAD MCP Server needs to export 3D models in formats that:
+1. Preserve parametric properties
+2. Support metadata
+3. Are compatible with Prusa and Bambu printers
+4. Avoid limitations of STL format
+
+<exploration>
+We evaluated multiple export formats:
+- STL: Traditional format but lacks metadata
+- CSG: OpenSCAD's native format, fully parametric
+- SCAD: Source code, fully parametric
+- 3MF: Modern format with metadata support
+- AMF: XML-based format with metadata
+- DXF/SVG: 2D formats for laser cutting
+</exploration>
+
+## Decision
+
+We will use **3MF as the primary export format** with AMF as a secondary option. 
+CSG and SCAD will be supported for users who want to modify the models in OpenSCAD.
+
+<mental-model>
+The ideal export format should:
+- Maintain all design parameters
+- Include metadata about the model
+- Be widely supported by popular slicers
+- Have a clean, standardized specification
+- Support multiple objects and materials
+</mental-model>
+
+## Rationale
+
+<pattern-recognition>
+Modern 3D printing workflows favor formats that preserve more information than just geometry. The industry is shifting from STL to more capable formats like 3MF.
+</pattern-recognition>
+
+- **3MF** is supported by both Prusa and Bambu printer software
+- **3MF** includes support for metadata, colors, and materials
+- **3MF** has a cleaner specification than STL
+- **AMF** offers similar advantages but with less widespread adoption
+- **CSG/SCAD** formats maintain full parametric properties but only within OpenSCAD
+
+<trade-off>
+We considered making STL an option for broader compatibility, but this would compromise our goal of preserving parametric properties. The benefits of 3MF outweigh the minor compatibility issues that might arise.
+</trade-off>
+
+## Consequences
+
+**Positive:**
+- Better preservation of model information
+- Improved compatibility with modern printer software
+- Future-proof approach as 3MF adoption increases
+
+**Negative:**
+- Slightly more complex implementation than STL
+- May require validation to ensure proper format compliance
+
+<technical-debt>
+We will need to implement validation for 3MF and AMF files to ensure they meet specifications. This adds complexity but is necessary for reliability.
+</technical-debt>
+
+<knowledge-refs>
+- [OpenSCAD Export Formats](/rtfmd/knowledge/openscad/export-formats.md)
+- [OpenSCAD Basics](/rtfmd/knowledge/openscad/openscad-basics.md)
+</knowledge-refs>

package/mcp_servers/openscad-mcp-server/legacy/rtfmd/files/src/ai/ai_service.py.md

@@ -0,0 +1,51 @@
+<metadata>
+  author: devin-ai-integration
+  timestamp: 2025-03-21T01:30:00Z
+  version: 1.0.0
+  related-files: [/src/models/code_generator.py]
+  prompt: "Implement AI-driven code generator for OpenSCAD"
+</metadata>
+
+<exploration>
+  The AI service component was designed to provide natural language processing capabilities for generating OpenSCAD code from user descriptions. Initial approaches considered:
+  
+  1. Using a template-based approach with predefined patterns
+  2. Implementing a full NLP pipeline with custom entity extraction
+  3. Creating a hybrid approach that combines pattern matching with contextual understanding
+  
+  The hybrid approach was selected as it provides flexibility while maintaining performance.
+</exploration>
+
+<mental-model>
+  The AI service operates on the concept of "component identification" - breaking down natural language descriptions into geometric primitives, operations, features, and modifiers. This mental model aligns with how OpenSCAD itself works, where complex models are built from primitive shapes and CSG operations.
+</mental-model>
+
+<pattern-recognition>
+  The implementation uses the Strategy pattern for different parsing strategies and the Factory pattern for code generation. These patterns allow for extensibility as new shape types or operations are added.
+</pattern-recognition>
+
+<trade-off>
+  Options considered:
+  1. Full machine learning approach with embeddings and neural networks
+  2. Rule-based pattern matching with regular expressions
+  3. Hybrid approach with pattern matching and contextual rules
+  
+  The hybrid approach was chosen because:
+  - Lower computational requirements than full ML
+  - More flexible than pure rule-based systems
+  - Easier to debug and maintain
+  - Can be extended with more sophisticated ML in the future
+</trade-off>
+
+<domain-knowledge>
+  The implementation required understanding of:
+  - OpenSCAD's modeling paradigm (CSG operations)
+  - Common 3D modeling terminology
+  - Natural language processing techniques
+  - Regular expression pattern matching
+</domain-knowledge>
+
+<knowledge-refs>
+  [OpenSCAD Basics](/rtfmd/knowledge/openscad/openscad-basics.md) - Last updated 2025-03-21
+  [Natural Language Processing](/rtfmd/knowledge/ai/natural-language-processing.md) - Last updated 2025-03-21
+</knowledge-refs>

package/mcp_servers/openscad-mcp-server/legacy/rtfmd/files/src/main.py.md

@@ -0,0 +1,63 @@
+<metadata>
+  author: devin-ai-integration
+  timestamp: 2025-03-21T01:30:00Z
+  version: 1.0.0
+  related-files: [/src/ai/ai_service.py, /src/models/code_generator.py, /src/nlp/parameter_extractor.py]
+  prompt: "Build an MCP server for OpenSCAD"
+</metadata>
+
+<exploration>
+  The main application was designed to implement a Model Context Protocol (MCP) server for OpenSCAD integration. Several approaches were considered:
+  
+  1. Using a standalone server with direct OpenSCAD CLI calls
+  2. Implementing a web service with REST API
+  3. Creating an MCP-compliant server with FastAPI
+  
+  The MCP-compliant FastAPI approach was selected for its alignment with the project requirements and modern API design.
+</exploration>
+
+<mental-model>
+  The main application operates on a "tool-based MCP service" paradigm, where each capability is exposed as an MCP tool that can be called by AI assistants. This mental model aligns with the MCP specification and provides a clean separation of concerns.
+</mental-model>
+
+<pattern-recognition>
+  The implementation uses the Facade pattern to provide a simple interface to the complex subsystems (parameter extraction, code generation, OpenSCAD wrapper, etc.). This pattern simplifies the client interface and decouples the subsystems from clients.
+</pattern-recognition>
+
+<trade-off>
+  Options considered:
+  1. Monolithic application with tightly coupled components
+  2. Microservices architecture with separate services
+  3. Modular monolith with clear component boundaries
+  
+  The modular monolith approach was chosen because:
+  - Simpler deployment and operation
+  - Lower latency for inter-component communication
+  - Easier to develop and debug
+  - Still maintains good separation of concerns
+</trade-off>
+
+<domain-knowledge>
+  The implementation required understanding of:
+  - Model Context Protocol (MCP) specification
+  - FastAPI framework
+  - OpenSCAD command-line interface
+  - 3D modeling and printing workflows
+</domain-knowledge>
+
+<technical-debt>
+  The current implementation has some limitations:
+  - In-memory storage of models (not persistent)
+  - Basic error handling
+  - Limited printer discovery capabilities
+  
+  Future improvements planned:
+  - Persistent storage for models
+  - Enhanced error handling and reporting
+  - More robust printer discovery and management
+</technical-debt>
+
+<knowledge-refs>
+  [OpenSCAD Basics](/rtfmd/knowledge/openscad/openscad-basics.md) - Last updated 2025-03-21
+  [AI-Driven Code Generation](/rtfmd/decisions/ai-driven-code-generation.md) - Last updated 2025-03-21
+</knowledge-refs>

package/mcp_servers/openscad-mcp-server/legacy/rtfmd/files/src/models/code_generator.py.md

@@ -0,0 +1,63 @@
+<metadata>
+  author: devin-ai-integration
+  timestamp: 2025-03-21T01:30:00Z
+  version: 1.0.0
+  related-files: [/src/ai/ai_service.py, /src/nlp/parameter_extractor.py]
+  prompt: "Implement AI-driven code generator for OpenSCAD"
+</metadata>
+
+<exploration>
+  The code generator was designed to translate natural language descriptions and extracted parameters into valid OpenSCAD code. Several approaches were considered:
+  
+  1. Direct string manipulation for code generation
+  2. Template-based approach with parameter substitution
+  3. Modular approach with separate modules for different shape types
+  
+  The modular approach was selected for its maintainability and extensibility.
+</exploration>
+
+<mental-model>
+  The code generator operates on a "shape-to-module" mapping paradigm, where each identified shape type corresponds to a specific OpenSCAD module. This mental model allows for clean separation of concerns and makes it easy to add new shape types.
+</mental-model>
+
+<pattern-recognition>
+  The implementation uses the Factory pattern for code generation, where different shape types are mapped to different module generators. This pattern allows for easy extension with new shape types.
+</pattern-recognition>
+
+<trade-off>
+  Options considered:
+  1. Generating raw OpenSCAD primitives directly
+  2. Using a library of pre-defined modules
+  3. Hybrid approach with both primitives and modules
+  
+  The library approach was chosen because:
+  - More maintainable and readable code
+  - Easier to implement complex shapes
+  - Better parameter handling
+  - More consistent output
+</trade-off>
+
+<domain-knowledge>
+  The implementation required understanding of:
+  - OpenSCAD syntax and semantics
+  - Constructive Solid Geometry (CSG) operations
+  - Parametric modeling concepts
+  - 3D geometry fundamentals
+</domain-knowledge>
+
+<technical-debt>
+  The current implementation has some limitations:
+  - Limited support for complex nested operations
+  - No support for custom user-defined modules
+  - Basic error handling for invalid parameters
+  
+  Future improvements planned:
+  - Enhanced error handling with meaningful messages
+  - Support for user-defined modules
+  - More sophisticated CSG operation chaining
+</technical-debt>
+
+<knowledge-refs>
+  [OpenSCAD Basics](/rtfmd/knowledge/openscad/openscad-basics.md) - Last updated 2025-03-21
+  [AI-Driven Code Generation](/rtfmd/decisions/ai-driven-code-generation.md) - Last updated 2025-03-21
+</knowledge-refs>

package/mcp_servers/openscad-mcp-server/legacy/rtfmd/files/src/nlp/parameter_extractor.py.md

@@ -0,0 +1,63 @@
+<metadata>
+  author: devin-ai-integration
+  timestamp: 2025-03-21T01:30:00Z
+  version: 1.0.0
+  related-files: [/src/models/code_generator.py]
+  prompt: "Enhance parameter extractor with expanded shape recognition"
+</metadata>
+
+<exploration>
+  The parameter extractor was designed to parse natural language descriptions and extract structured parameters for 3D model generation. Several approaches were considered:
+  
+  1. Using a full NLP pipeline with named entity recognition
+  2. Implementing regex-based pattern matching
+  3. Creating a hybrid approach with contextual understanding
+  
+  The regex-based approach with contextual enhancements was selected for its balance of simplicity and effectiveness.
+</exploration>
+
+<mental-model>
+  The parameter extractor operates on a "pattern recognition and extraction" paradigm, where common phrases and patterns in natural language are mapped to specific parameter types. This mental model allows for intuitive parameter extraction from diverse descriptions.
+</mental-model>
+
+<pattern-recognition>
+  The implementation uses the Strategy pattern for different parameter extraction strategies based on shape type. This pattern allows for specialized extraction logic for each shape type while maintaining a consistent interface.
+</pattern-recognition>
+
+<trade-off>
+  Options considered:
+  1. Machine learning-based approach with trained models
+  2. Pure regex pattern matching
+  3. Hybrid approach with contextual rules
+  
+  The regex approach with contextual rules was chosen because:
+  - Simpler implementation with good accuracy
+  - No training data required
+  - Easier to debug and maintain
+  - More predictable behavior
+</trade-off>
+
+<domain-knowledge>
+  The implementation required understanding of:
+  - Natural language processing concepts
+  - Regular expression pattern matching
+  - 3D modeling terminology
+  - Parameter types for different geometric shapes
+</domain-knowledge>
+
+<technical-debt>
+  The current implementation has some limitations:
+  - Limited support for complex nested descriptions
+  - Regex patterns may need maintenance as language evolves
+  - Only supports millimeters as per project requirements
+  
+  Future improvements planned:
+  - Enhanced contextual understanding
+  - Support for more complex descriptions
+  - Better handling of ambiguous parameters
+</technical-debt>
+
+<knowledge-refs>
+  [Parameter Extraction](/rtfmd/knowledge/nlp/parameter-extraction.md) - Last updated 2025-03-21
+  [Natural Language Processing](/rtfmd/knowledge/ai/natural-language-processing.md) - Last updated 2025-03-21
+</knowledge-refs>