chore: update rules

Author: moonmeister

.copilot-rules.md

@@ -24,6 +24,58 @@
 - `plugins/` - WordPress plugins
 - `site/` - Project website
 
+## Development Philosophy
+
+### Simplicity Over Complexity
+
+- Start with the simplest solution that works, then add complexity only when absolutely necessary
+- If you find yourself building complex abstractions, step back and ask if a simpler approach exists
+- Prefer explicit, obvious code over "magic" that hides implementation details
+- Question whether template registries, complex HOCs, or automated systems are actually needed
+
+### Headless-First Design
+
+- Don't take over entire systems (routing, rendering, etc.) - provide utilities that developers can compose
+- Give developers control over their implementation rather than imposing opinionated frameworks
+- If it feels like "magic," it's probably too opinionated for a headless system
+- Provide core utilities and let developers implement their own data fetching and routing logic
+
+### Reuse Before Reimplementing
+
+- Check if functionality already exists in shared packages before writing new code
+- When improving shared functionality, update the shared package rather than working around it
+- Don't duplicate logic across framework-specific implementations
+- Use existing functions like `getTemplate` instead of reimplementing the same logic
+
+## Technical Implementation Guidelines
+
+### Environment Variables
+
+- Use semantic names (`WORDPRESS_URL`) over technical ones (`GRAPHQL_ENDPOINT`)
+- Let packages handle technical details (like appending `/index.php?graphql`)
+- Default to WordPress conventions (prefer `/index.php?graphql` over `/graphql`)
+
+### Framework Organization
+
+- Keep framework-agnostic utilities at main package level
+- Put framework-specific code under subpaths (`/pages`, `/app`, etc.)
+- Each framework handles its own specific needs (paths, imports, etc.) in its own layer
+- Example: Astro needs file paths, Next.js only needs template IDs
+
+### Dynamic Imports Structure
+
+- Use `next/dynamic` in template index files, not in page components
+- Keep loading states and code splitting organized at the template level
+- Import the configured templates directly in pages
+- Structure: `wp-templates/index.js` exports dynamic components, pages import and use them
+
+### Backward Compatibility
+
+- Don't add complexity for unreleased versions
+- Clean up deprecated patterns before they become public API
+- Focus on the best API design rather than supporting every iteration
+- Remove fallbacks for functionality that was never released
+
 ## Code Standards
 
 ### TypeScript/JavaScript