|
| 1 | +# GitHub Copilot Instructions |
| 2 | + |
| 3 | +## Development Philosophy & Environment Awareness |
| 4 | + |
| 5 | +### Understanding Your Working Environment |
| 6 | + |
| 7 | +Before implementing solutions, always consider the environment and tools you're working with: |
| 8 | + |
| 9 | +**Browser/DOM Environment:** |
| 10 | + |
| 11 | +- DOM operations are asynchronous and may require timing considerations |
| 12 | +- Browser APIs like `scrollTo()` can be unreliable without proper fallbacks |
| 13 | +- Always verify that DOM manipulations actually occurred (don't assume success) |
| 14 | +- Use multiple approaches: try modern APIs first, then fallback to legacy methods |
| 15 | +- Consider render timing - operations may need delays or `requestAnimationFrame` |
| 16 | + |
| 17 | +**React/Component Environment:** |
| 18 | + |
| 19 | +- State updates are asynchronous and may cause re-renders that interfere with DOM operations |
| 20 | +- useEffect dependencies can cause infinite loops if not carefully managed |
| 21 | +- Refs provide stable references to DOM elements across renders |
| 22 | +- Consider component lifecycle when timing DOM operations |
| 23 | + |
| 24 | +**General Environment Principles:** |
| 25 | + |
| 26 | +- **Test assumptions**: Don't assume an API call worked - verify the result |
| 27 | +- **Provide fallbacks**: Always have backup approaches for critical functionality |
| 28 | +- **Add debugging**: Include logging to understand what's actually happening |
| 29 | +- **Consider timing**: Many issues are timing-related, especially with async operations |
| 30 | +- **Understand constraints**: Each environment has limitations (browser security, React lifecycle, etc.) |
| 31 | + |
| 32 | +### Problem-Solving Approach |
| 33 | + |
| 34 | +1. **Analyze the environment** - What tools, frameworks, and constraints are you working with? |
| 35 | +2. **Understand the flow** - How do data, events, and updates move through the system? |
| 36 | +3. **Identify failure points** - Where might things go wrong? What are the edge cases? |
| 37 | +4. **Design resilient solutions** - Include error handling, fallbacks, and verification |
| 38 | +5. **Add observability** - Include logging/debugging to understand actual behavior |
| 39 | +6. **Test incrementally** - Verify each step works before building on it |
| 40 | + |
| 41 | +### Implementation Guidelines |
| 42 | + |
| 43 | +**For DOM/Browser Work:** |
| 44 | + |
| 45 | +- Use feature detection before modern APIs |
| 46 | +- Implement progressive enhancement (basic functionality first, enhancements after) |
| 47 | +- Add timing delays or RAF when DOM needs to settle |
| 48 | +- Verify operations completed successfully |
| 49 | + |
| 50 | +**For React/State Management:** |
| 51 | + |
| 52 | +- Minimize useEffect dependencies to prevent loops |
| 53 | +- Use refs for values that shouldn't trigger re-renders |
| 54 | +- Consider component lifecycle timing for DOM operations |
| 55 | +- Separate concerns: state updates vs DOM manipulation |
| 56 | + |
| 57 | +**For Any Environment:** |
| 58 | + |
| 59 | +- Start with the simplest approach that could work |
| 60 | +- Add complexity only when simple approaches fail |
| 61 | +- Document why complex solutions are needed |
| 62 | +- Make code readable - future developers need to understand the constraints you solved for |
| 63 | + |
| 64 | +This approach applies whether working with databases, APIs, file systems, mobile environments, or any other development context. The key is understanding your tools and environment before implementing solutions. |
| 65 | + |
| 66 | +## Masterbots Monorepo Architecture |
| 67 | + |
| 68 | +### Understanding the System Architecture |
| 69 | + |
| 70 | +The masterbots platform follows modern web application patterns with clear separation of concerns: |
| 71 | + |
| 72 | +**Core Applications:** |
| 73 | + |
| 74 | +- `apps/web/` - Main Next.js chat interface |
| 75 | +- `apps/pro-web/` - Pro workspace editor (current focus) |
| 76 | +- `apps/hasura/` - GraphQL API and database layer |
| 77 | + |
| 78 | +**Shared Packages:** |
| 79 | + |
| 80 | +- `packages/mb-genql/` - Generated GraphQL client for type-safe API calls |
| 81 | +- `packages/mb-lib/` - Shared utilities and helpers |
| 82 | +- `packages/mb-types/` - Common TypeScript type definitions |
| 83 | +- `packages/mb-env/` - Environment configuration |
| 84 | +- `packages/mb-drizzle/` - Database schema and migrations |
| 85 | + |
| 86 | +### State Management Patterns |
| 87 | + |
| 88 | +When working with the masterbots codebase, follow established patterns: |
| 89 | + |
| 90 | +**Provider Architecture:** |
| 91 | + |
| 92 | +- Use hierarchical provider structure for global state |
| 93 | +- Custom hooks (`useMBChat`, `useThread`, `useSidebar`, `useModel`) manage domain-specific concerns |
| 94 | +- Keep providers focused and compose them hierarchically |
| 95 | + |
| 96 | +**Data Flow:** |
| 97 | + |
| 98 | +- Follow unidirectional data flow: User Input → Component State → Custom Hooks → Server Actions → Database |
| 99 | +- Use `hasura.service.ts` for all GraphQL operations |
| 100 | +- Leverage IndexedDB for local caching and immediate UI updates |
| 101 | + |
| 102 | +**Component Composition:** |
| 103 | + |
| 104 | +- Build complex components by composing smaller, focused components |
| 105 | +- Separate presentation from business logic |
| 106 | +- Use custom hooks to encapsulate complex state logic |
| 107 | + |
| 108 | +### AI Integration Environment |
| 109 | + |
| 110 | +The platform integrates multiple AI providers with specific patterns: |
| 111 | + |
| 112 | +**Model Management:** |
| 113 | + |
| 114 | +- Use `getModelClientType()` to determine appropriate AI client |
| 115 | +- Route through `ai-main-call.actions` for unified AI API handling |
| 116 | +- Support multiple providers (OpenAI, Anthropic, etc.) through consistent interfaces |
| 117 | + |
| 118 | +**Chat System:** |
| 119 | + |
| 120 | +- `useMBChat` orchestrates all chat functionality |
| 121 | +- Integrate with AI SDK's `useChat` hook for streaming responses |
| 122 | +- Handle file attachments through hybrid storage (IndexedDB + Cloud Storage) |
| 123 | + |
| 124 | +### GraphQL Integration |
| 125 | + |
| 126 | +All data operations follow consistent patterns: |
| 127 | + |
| 128 | +**Service Layer:** |
| 129 | + |
| 130 | +- Use `hasura.service.ts` as the single point of GraphQL interaction |
| 131 | +- Generated types from `mb-genql` ensure type safety |
| 132 | +- Abstract Hasura-specific details behind service methods |
| 133 | + |
| 134 | +**Error Handling:** |
| 135 | + |
| 136 | +- GraphQL operations can fail at network, parsing, or business logic levels |
| 137 | +- Always handle partial success scenarios |
| 138 | +- Provide meaningful fallbacks for degraded functionality |
| 139 | + |
| 140 | +### Development Guidelines |
| 141 | + |
| 142 | +**File Organization:** |
| 143 | + |
| 144 | +- Components: `components/routes/[feature]/` for page-specific components |
| 145 | +- Shared Components: `components/shared/` for reusable UI elements |
| 146 | +- Hooks: `lib/hooks/` for custom React hooks |
| 147 | +- Services: `services/` for external API integrations |
| 148 | +- Types: `types/` for TypeScript definitions |
| 149 | + |
| 150 | +**External Documentation:** |
| 151 | + |
| 152 | +- [DeepWiki Documentation](https://deepwiki.com/bitcashorg/masterbots) - Comprehensive system overview |
| 153 | +- [Hasura GraphQL](https://hasura.io/docs/) - GraphQL API patterns |
| 154 | +- [Next.js App Router](https://nextjs.org/docs/app) - Routing and server components |
| 155 | +- [AI SDK](https://sdk.vercel.ai/docs) - AI integration patterns |
| 156 | + |
| 157 | +**Working with Pro Workspace:** |
| 158 | + |
| 159 | +- Editor components follow controlled/uncontrolled patterns |
| 160 | +- Markdown processing uses dedicated utility functions |
| 161 | +- Section management requires careful state synchronization |
| 162 | +- Auto-scroll and DOM manipulation need timing considerations (as demonstrated in recent work) |
| 163 | + |
| 164 | +Remember: Each layer of the stack has its own constraints and capabilities. Always consider the full data flow from user interaction to database persistence when implementing features. |
0 commit comments