# FikoCAD Geometry Pipeline Engine (GPE) ## Claude Opus 4.8 Mimari Geliştirme Planı Bu doküman, Geometry Pipeline Engine (GPE) geliştirme sürecini aşamalara ayırır. Amaç, Opus 4.8'i doğrudan kod yazdırmak için değil, sistem mimarı olarak kullanarak üretim seviyesinde bir altyapı tasarlamaktır. ------------------------------------------------------------------------ # PHASE 1 --- System Architecture You are the Chief Software Architect of the FikoCAD platform. You are NOT allowed to write implementation code. Your job is to design the architecture only. We are building a completely new subsystem called Geometry Pipeline Engine (GPE) The Geometry Pipeline Engine is inspired by MongoDB Aggregation Pipeline, SQL Query Optimizer, LLVM Pass Pipeline and modern ECS architectures. This engine is NOT a database. It is a semantic execution engine for CAD models. The platform already contains: • Native B-Rep Kernel • Geometry Engine • Geometry Intelligence Engine (GIE) The Geometry Intelligence Engine generates semantic information about every topology entity. The new Geometry Pipeline Engine will consume that information. Its purpose is to become the central execution layer of the entire platform. Every subsystem must communicate using pipelines. Examples: CAD CAM CAE Inspection Casting AI Automation Manufacturing Reporting Visualization Simulation must all use the same pipeline engine. The pipeline must support: • Fluent C++ API • JSON • Visual Node Graph All three representations must compile into the same execution plan. Pipeline ↓ Parser ↓ AST ↓ Optimizer ↓ Execution Plan ↓ Execution Engine The pipeline must be immutable. Support: • Lazy evaluation • Incremental execution • Stage optimization • Parallel execution • SIMD • Plugin stages • Dependency tracking • Result caching • Thread safety Produce an RFC-style architecture document including: 1. Goals 2. Non Goals 3. Requirements 4. High Level Architecture 5. Pipeline Lifecycle 6. Component Diagram 7. Data Flow 8. Memory Strategy 9. Threading Strategy 10. Plugin Strategy 11. Performance Strategy 12. Error Strategy 13. Future Extensions 14. Risks 15. Alternative Designs 16. Recommended Design ------------------------------------------------------------------------ # PHASE 2 --- JSON Specification Design the complete JSON Specification. Do not write C++. Design only the JSON language. Think like MongoDB Aggregation Pipeline mixed with GraphQL and CAD. Include: - Grammar - Keywords - Reserved Words - Validation Rules - Pipeline Schema - Stage Schema - Expression Schema - References - Variables - Constants - Functions - Conditions - Branching - Loops (if needed) - Stage Metadata - Plugin Metadata - Versioning - Backward Compatibility - Deprecation Strategy Produce something similar to the JSON Schema RFC. ------------------------------------------------------------------------ # PHASE 3 --- Fluent C++20 API Design the Fluent C++20 API. Do not implement. Design only the public API. The Fluent API and JSON must always generate exactly the same AST. Inspired by: - MongoDB Aggregate - LINQ - C++ Ranges - STL - LLVM Pass Manager - Qt Fluent APIs Explain: - Naming conventions - Overloads - Templates - Concepts - Compile-time validation - Runtime validation - Extension points ------------------------------------------------------------------------ # PHASE 4 --- AST Design the Pipeline AST. Explain: - Node hierarchy - Ownership - Visitors - Transformations - Immutable updates - Memory layout Think like LLVM. ------------------------------------------------------------------------ # PHASE 5 --- Optimizer Design optimizer passes. Include: - Stage Fusion - Match Merging - Projection Pruning - Dead Stage Elimination - Constant Folding - Predicate Pushdown - Lookup Optimization - Parallel Scheduling - SIMD Opportunities - Cost Estimation - Execution Planning ------------------------------------------------------------------------ # PHASE 6 --- Execution Engine Design: - Execution Context - Execution Graph - Scheduler - Executors - Result Streams - Iterators - Cancellation - Transactions - Thread Pools - Incremental Updates - Dependency Graph - Memory Pools - Cache Strategy - Profiling - Tracing ------------------------------------------------------------------------ # PHASE 7 --- Plugin SDK Design a plugin SDK that allows: - Custom Stages - Custom Expressions - Custom Validators - Custom Exporters - Custom Visual Nodes - Custom AI Modules Design: - Registration - ABI Stability - Loading - Sandboxing - Permissions - Version Compatibility Inspired by Unreal Engine Plugins. ------------------------------------------------------------------------ # PHASE 8 --- Visual Pipeline Editor Inspired by: - Unreal Blueprints - Blender Geometry Nodes - NVIDIA Omniverse Graph Include: - Nodes - Pins - Connections - Validation - Debugging - Breakpoints - Execution Visualization - Undo/Redo - Search - Templates - Sub Pipelines - Macros - Node Libraries - Favorites - Comments - Groups - Documentation ------------------------------------------------------------------------ # PHASE 9 --- Testing Strategy Design: - Unit Tests - Integration Tests - Performance Tests - Stress Tests - Memory Tests - Plugin Tests - Serialization Tests - Compatibility Tests - Regression Tests - Golden Tests - Benchmark Strategy ------------------------------------------------------------------------ # PHASE 10 --- Production Structure Generate: - Folder Structure - Namespaces - Modules - Interfaces - Base Classes - Coding Guidelines - Naming Conventions - Dependency Rules - CMake Structure - Documentation Structure No business logic. Only production-ready architecture. ------------------------------------------------------------------------ ## Recommended Workflow Architecture ↓ JSON Language ↓ Fluent API ↓ AST ↓ Optimizer ↓ Execution Engine ↓ Plugin SDK ↓ Visual Editor ↓ Testing ↓ Implementation