|
| 1 | +# AGENTS.md |
| 2 | + |
| 3 | +This file provides guidance to Codex (Codex.ai/code) when working with code in this repository. |
| 4 | + |
| 5 | +## Project Overview |
| 6 | + |
| 7 | +**Fulling v2** is an AI-powered development platform that integrates AI Agent ecosystem to provide full-stack development capabilities. Users can import existing projects from GitHub or create new projects directly on the platform. |
| 8 | + |
| 9 | +**Core Value**: Free users' mental bandwidth through AI Agents. Users focus on development while Agents silently handle complex operations (deployment, infrastructure, etc.) without interruption. |
| 10 | + |
| 11 | +**Key Features**: |
| 12 | +- **Flexible Project Creation**: Import from GitHub repositories or create new projects from scratch |
| 13 | +- **Optional Database**: Add PostgreSQL database on-demand when needed |
| 14 | +- **AI Agent Ecosystem**: AI agents handle development, testing, deployment, and infrastructure management |
| 15 | +- **Automated Operations**: Deployment, scaling, and infrastructure management happen automatically in the background |
| 16 | +- **Full-Stack Development**: Complete environment with optional database, terminal, and file management |
| 17 | +- **Zero Infrastructure Knowledge Required**: Users don't need to understand Kubernetes, networking, or DevOps |
| 18 | + |
| 19 | +**Architecture**: The platform uses an **asynchronous reconciliation pattern** where API endpoints return immediately and background jobs sync desired state (database) with actual state (Kubernetes) every 3 seconds. |
| 20 | + |
| 21 | +## Tech Stack |
| 22 | + |
| 23 | +### Frontend |
| 24 | +- Framework: Next.js 16 (App Router) + React 19 |
| 25 | +- Language: TypeScript |
| 26 | +- Styling: Tailwind CSS v4 |
| 27 | +- UI Components: Shadcn/UI |
| 28 | + |
| 29 | +### Backend |
| 30 | +- Runtime: Node.js 22 |
| 31 | +- API: Next.js API Routes |
| 32 | +- Database ORM: Prisma |
| 33 | +- Authentication: NextAuth v5 (GitHub, Password, Sealos OAuth) |
| 34 | + |
| 35 | +### Infrastructure |
| 36 | +- Container Orchestration: Kubernetes |
| 37 | +- Database: PostgreSQL (via KubeBlocks) |
| 38 | +- Web Terminal: ttyd (HTTP Basic Auth) |
| 39 | +- File Manager: FileBrowser |
| 40 | + |
| 41 | +## Key Conventions |
| 42 | + |
| 43 | +### Code Style |
| 44 | +- Use TypeScript strict mode |
| 45 | +- Always follow best practices |
| 46 | +- Write self-documenting code: for complex functions, describe purpose, expected inputs, and expected outputs above the function |
| 47 | +- Use functional components with hooks |
| 48 | + |
| 49 | +### Naming Conventions |
| 50 | +- K8s resources: `{k8s-project-name}-{resource-type}-{6chars}` |
| 51 | +- Environment variables: `UPPER_SNAKE_CASE` |
| 52 | +- Database tables: PascalCase (Prisma models) |
| 53 | +- API routes: kebab-case |
| 54 | +- Files: kebab-case |
| 55 | + |
| 56 | +### Component Organization |
| 57 | +- **Route-specific components**: Place in `_components/` directory under the route folder |
| 58 | + - Use `_` prefix to prevent Next.js from treating it as a route |
| 59 | + - Example: `app/(dashboard)/settings/_components/github-status-card.tsx` |
| 60 | +- **Shared components**: Place in top-level `components/` directory |
| 61 | + - Only for components used across multiple routes |
| 62 | + - Example: `components/ui/button.tsx`, `components/sidebar.tsx` |
| 63 | + |
| 64 | +### Important Patterns |
| 65 | + |
| 66 | +1. **Always use user-specific K8s service**: |
| 67 | + ```typescript |
| 68 | + const k8sService = await getK8sServiceForUser(userId) |
| 69 | + ``` |
| 70 | + |
| 71 | +2. **API endpoints are non-blocking**: |
| 72 | + - Only update database |
| 73 | + - Return immediately |
| 74 | + - Reconciliation jobs handle K8s operations |
| 75 | + |
| 76 | +3. **Use optimistic locking**: |
| 77 | + - Repository layer handles locking automatically |
| 78 | + - Prevents concurrent updates |
| 79 | + |
| 80 | +4. **Follow reconciliation pattern**: |
| 81 | + - API → Database → Reconciliation Job → Event → K8s Operation |
| 82 | + - Status updates happen asynchronously |
| 83 | + |
| 84 | +## Key Design Decisions |
| 85 | + |
| 86 | +### Why StatefulSet? |
| 87 | +- Persistent storage for each pod |
| 88 | +- Stable network identities |
| 89 | +- Ordered pod deployment |
| 90 | + |
| 91 | +### Why Reconciliation Pattern? |
| 92 | +- Non-blocking API responses |
| 93 | +- Automatic recovery from failures |
| 94 | +- Consistent state management |
| 95 | +- Easy to monitor and debug |
| 96 | + |
| 97 | +### Why User-Specific Namespaces? |
| 98 | +- Multi-tenancy isolation |
| 99 | +- Resource quotas per user |
| 100 | +- Separate kubeconfig per user |
| 101 | +- No cross-user access |
| 102 | + |
| 103 | +## Project Structure |
| 104 | + |
| 105 | +``` |
| 106 | +Fulling/ |
| 107 | +├── app/ # Next.js App Router |
| 108 | +│ ├── api/ # API Routes |
| 109 | +│ ├── (auth)/ # Auth pages |
| 110 | +│ └── (dashboard)/projects/[id]/ |
| 111 | +│ └── _components/ # Route-specific components |
| 112 | +│ |
| 113 | +├── components/ # Shared components |
| 114 | +├── hooks/ # Client-side hooks |
| 115 | +│ |
| 116 | +├── lib/ |
| 117 | +│ ├── data/ # Server-side data access (for Server Components) |
| 118 | +│ ├── actions/ # Client-side data access (Server Actions) |
| 119 | +│ ├── repo/ # Repository layer with optimistic locking |
| 120 | +│ ├── services/ # Business logic services |
| 121 | +│ ├── events/ # Event bus and listeners |
| 122 | +│ ├── jobs/ # Reconciliation background jobs |
| 123 | +│ ├── startup/ # Application initialization |
| 124 | +│ ├── k8s/ # Kubernetes operations |
| 125 | +│ └── util/ # Utility functions |
| 126 | +│ |
| 127 | +├── prisma/ # Prisma schema |
| 128 | +├── provider/ # React Context providers |
| 129 | +├── runtime/ # Sandbox Docker image |
| 130 | +└── yaml/ # Kubernetes templates |
| 131 | +``` |
| 132 | + |
| 133 | +**Key Directories**: |
| 134 | +- `lib/data/` - Server-side data access, used by Server Components |
| 135 | +- `lib/actions/` - Server Actions, used by Client Components |
| 136 | +- `lib/repo/` - Repository with optimistic locking, used by Jobs/Events |
| 137 | +- `lib/events/` + `lib/jobs/` - Core of reconciliation pattern |
| 138 | +- `lib/startup/` - Initializes event listeners and reconciliation jobs |
| 139 | + |
| 140 | +## Documentation Index |
| 141 | + |
| 142 | +- [Architecture](./docs/architecture.md) - Reconciliation pattern, event system, state management |
| 143 | +- [Development Guide](./docs/development.md) - Local development, code patterns, testing |
| 144 | +- [Operations Manual](./docs/operations.md) - Deployment, monitoring, K8s operations |
| 145 | +- [Troubleshooting](./docs/troubleshooting.md) - Common issues, debugging commands |
| 146 | + |
| 147 | +## Quick Reference |
| 148 | + |
| 149 | +### Development Commands |
| 150 | +```bash |
| 151 | +pnpm dev # Start dev server |
| 152 | +pnpm build # Build for production |
| 153 | +pnpm lint # Run ESLint |
| 154 | +npx prisma generate # Generate Prisma client |
| 155 | +npx prisma db push # Push schema to database |
| 156 | +``` |
| 157 | + |
| 158 | +### Key Files |
| 159 | +- `lib/k8s/k8s-service-helper.ts` - User-specific K8s service |
| 160 | +- `lib/events/sandbox/sandboxListener.ts` - Sandbox lifecycle handlers |
| 161 | +- `lib/jobs/sandbox/sandboxReconcile.ts` - Sandbox reconciliation job |
| 162 | +- `lib/events/database/databaseListener.ts` - Database lifecycle handlers |
| 163 | +- `lib/jobs/database/databaseReconcile.ts` - Database reconciliation job |
| 164 | +- `lib/actions/project.ts` - Project creation (creates Sandbox only) |
| 165 | +- `lib/actions/database.ts` - Database creation/deletion (on-demand) |
| 166 | +- `prisma/schema.prisma` - Database schema |
| 167 | +- `instrumentation.ts` - Application startup |
| 168 | + |
| 169 | +### Environment Variables |
| 170 | +- `DATABASE_URL` - Main app database connection |
| 171 | +- `NEXTAUTH_SECRET` - NextAuth secret |
| 172 | +- `GITHUB_CLIENT_ID` / `GITHUB_CLIENT_SECRET` - GitHub OAuth |
| 173 | +- `SEALOS_JWT_SECRET` - Sealos OAuth validation |
| 174 | +- `RUNTIME_IMAGE` - Container image version |
| 175 | + |
| 176 | +### Resource Status |
| 177 | +- `CREATING` → `STARTING` → `RUNNING` ⇄ `STOPPING` → `STOPPED` |
| 178 | +- `UPDATING` - Environment variables being updated |
| 179 | +- `TERMINATING` → `TERMINATED` |
| 180 | +- `ERROR` - Operation failed |
| 181 | + |
| 182 | +### Port Exposure |
| 183 | +- **3000**: Next.js application |
| 184 | +- **7681**: ttyd web terminal |
| 185 | +- **8080**: FileBrowser (file manager) |
| 186 | + |
| 187 | +## Important Notes |
| 188 | + |
| 189 | +- **Project Resources**: Each project includes a Sandbox (required) and can optionally have a Database (PostgreSQL). Database can be added on-demand after project creation. |
| 190 | +- **Reconciliation Delay**: Status updates may take up to 3 seconds |
| 191 | +- **User-Specific Namespaces**: Each user operates in their own K8s namespace |
| 192 | +- **Frontend Polling**: Client components poll every 3 seconds for status updates |
| 193 | +- **Database Wait Time**: PostgreSQL cluster takes 2-3 minutes to reach "Running" (when added) |
| 194 | +- **Idempotent Operations**: All K8s methods can be called multiple times safely |
| 195 | +- **Lock Duration**: Optimistic locks held for 30 seconds |
| 196 | +- **Deployment Domain**: Main app listens on `0.0.0.0:3000` (not localhost) for Sealos |
0 commit comments