@full-self-developing/fsd 1.0.0

package/skills/ai-error-prevention/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: ai-error-prevention
+description: Log of AI development errors and prevention strategies for TheOMS (ThinkPHP 5.0)
+version: 1.0.0
+---
+
+# AI Error Prevention Log
+
+This document tracks common mistakes made by AI coding assistants in this repository to prevent regression and ensure code quality.
+
+## 1. View & Template Errors (ThinkPHP 5.0)
+
+### 1.1 Missing Template Extension Tags
+- **Error**: Creating or refactoring a view file (e.g., `achieve.html`) but forgetting to include `{extend name="..." /}` and `{block name="..."}`.
+- **Consequence**: The page renders as a standalone HTML fragment without CSS, JS libraries (Vue, Element Plus), or layout, often leading to a blank screen or a "Template error".
+- **Prevention**: 
+    - Always check if the view should extend a base layout (e.g., `main/vue3`).
+    - Ensure all content is wrapped in the correct `{block}` (usually `head` or `main`).
+    - Verify that every `{block}` has a corresponding `{/block}`.
+
+### 1.2 Vue 3 `.native` Modifier
+- **Error**: Using `@keyup.enter.native` or similar `.native` modifiers in Vue 3 templates.
+- **Consequence**: In Vue 3, `.native` was removed. It may cause event listeners to fail or warnings in the console.
+- **Prevention**: Use standard `@keyup.enter` or the appropriate event names for Element Plus components.
+
+## 2. Controller & Logic Errors
+
+### 2.1 Missing Input Validation
+- **Error**: Directly using `input('post.')` without passing it through a ThinkPHP `Validate` class.
+- **Consequence**: Security vulnerabilities (SQLi, XSS) and data corruption.
+- **Prevention**: 
+    - Always use `application/common/validate` classes.
+    - Call `$this->validate($input, 'ValidateClassName.scene')` in controllers.
+
+### 2.2 N+1 Query Issues
+- **Error**: Placing database queries (`db()->where()->find()`) inside a `foreach` loop.
+- **Consequence**: Severe performance degradation when processing large datasets.
+- **Prevention**: 
+    - Use ORM associations (`hasOne`, `belongsTo`) and eager loading via `with()`.
+    - Batch fetch data using `whereIn` before the loop.
+
+### 2.3 Token Header/Cookie Mismatch
+- **Error**: Frontend sends `Authorization: Bearer <token>` while backend token validation expects the raw token string, and backend gives the header priority over a valid `admin_token` cookie.
+- **Consequence**: Browser pages can successfully load with the cookie, then API calls return `code:401`; frontend removes `localStorage.admin_token` and redirects to `/`, which may 302 back to `main.html`.
+- **Prevention**:
+    - Normalize `Authorization` headers by stripping the `Bearer ` prefix before validation.
+    - Keep cookie auth as a fallback when a header token fails validation.
+    - Add regression tests for both Bearer header parsing and cookie fallback behavior.
+
+### 2.4 Refactoring Data Types (JSON string to Array)
+- **Error**: Refactoring a service method (e.g., `RankService::getRankInfo`) to return a decoded array internally, but forgetting to remove `json_decode()` wrappers at all controller call sites.
+- **Consequence**: Throws `ErrorException: json_decode() expects parameter 1 to be string, array given`, leading to API 500 errors.
+- **Prevention**:
+    - When changing a method's return type (e.g., from JSON string to Array), perform a global search (`grep`) for all callers of that method.
+    - Inspect each caller to see if they apply string-specific operations (like `json_decode`) to the returned value and update them synchronously.
+
+## 3. Database & Migration Errors
+
+### 3.1 Field Name Mismatch (JSON Refactoring)
+- **Error**: Updating frontend components to use new JSON fields (e.g., `rule_config`) but forgetting to update the backend saving logic, or vice versa.
+- **Consequence**: Data loss or "Undefined index" errors in PHP.
+- **Prevention**: 
+    - Ensure `syn_sql` helper only filters fields that actually exist in the table.
+    - Keep legacy fields as "read-only backups" if necessary during migration.
+
+### 3.2 ThinkPHP 5.0 Query Builder `where` Cleared After `count()`
+- **Error**: Reusing the same `$query` builder instance to execute a `count()` query and then a paginated `select()` query.
+- **Consequence**: In ThinkPHP 5.0, executing `count()` on a query object automatically **clears** its compiled `where` conditions. Subsequent `select()` calls will run without any filter constraints, returning all rows from the table.
+- **Prevention**:
+    - **Separate Query Instances**: Always query count and page select separately.
+      ```php
+      $count = Model::where($sql)->count();
+      if ($count) {
+          $list = Model::with(['relation'])->where($sql)->page($page, $limit)->select();
+      }
+      ```
+    - **Eager Loading**: Never eager load relations (`with()`) on the `count()` query itself. Separating the count query also improves query performance since the database doesn't need to join tables or evaluate relations just to count rows.
+
+## 4. Mini-Program & Cross-Platform Errors
+
+### 4.1 Global Variable Scope
+- **Error**: Assuming `getApp()` or `this.data` in mini-programs (wxapp) behaves exactly like React/Vue state.
+- **Consequence**: Data synchronization issues or crashes in specific mini-program versions.
+- **Prevention**: 
+    - Always use `this.setData()` for UI updates.
+    - Validate `app.globalData` existence before access.
+
+### 4.2 Path Case Sensitivity
+- **Error**: Referencing files or components with incorrect case (e.g., `store/Achieve` vs `store/achieve`).
+- **Consequence**: Works on Windows (case-insensitive) but fails on Linux servers.
+- **Prevention**: Always use lowercase for file and directory names in the project.
+
+## 5. Coding Style & Standard Regressions
+
+### 5.1 Mixed PSR Standards
+- **Error**: Writing camelCase for variables while the rest of the file uses snake_case, or vice-versa.
+- **Consequence**: Poor readability and linting failures.
+- **Prevention**: Check surrounding code style before adding new variables or functions. For TheOMS, PHP uses snake_case for local variables and camelCase for modern service methods.
+
+---
+
+## How to use this Skill
+1. **Before starting a task**: Review the "Common Errors" section to identify relevant risks.
+2. **During development**: Check if your proposed changes follow the "Prevention" guidelines.
+3. **After fixing a bug**: If the bug was caused by an AI-generated mistake, record it here following the existing format.

package/skills/api-design/SKILL.md

@@ -0,0 +1,523 @@
+---
+name: api-design
+description: REST API design patterns including resource naming, status codes, pagination, filtering, error responses, versioning, and rate limiting for production APIs.
+origin: ECC
+---
+
+# API Design Patterns
+
+Conventions and best practices for designing consistent, developer-friendly REST APIs.
+
+## When to Activate
+
+- Designing new API endpoints
+- Reviewing existing API contracts
+- Adding pagination, filtering, or sorting
+- Implementing error handling for APIs
+- Planning API versioning strategy
+- Building public or partner-facing APIs
+
+## Resource Design
+
+### URL Structure
+
+```
+# Resources are nouns, plural, lowercase, kebab-case
+GET    /api/v1/users
+GET    /api/v1/users/:id
+POST   /api/v1/users
+PUT    /api/v1/users/:id
+PATCH  /api/v1/users/:id
+DELETE /api/v1/users/:id
+
+# Sub-resources for relationships
+GET    /api/v1/users/:id/orders
+POST   /api/v1/users/:id/orders
+
+# Actions that don't map to CRUD (use verbs sparingly)
+POST   /api/v1/orders/:id/cancel
+POST   /api/v1/auth/login
+POST   /api/v1/auth/refresh
+```
+
+### Naming Rules
+
+```
+# GOOD
+/api/v1/team-members          # kebab-case for multi-word resources
+/api/v1/orders?status=active  # query params for filtering
+/api/v1/users/123/orders      # nested resources for ownership
+
+# BAD
+/api/v1/getUsers              # verb in URL
+/api/v1/user                  # singular (use plural)
+/api/v1/team_members          # snake_case in URLs
+/api/v1/users/123/getOrders   # verb in nested resource
+```
+
+## HTTP Methods and Status Codes
+
+### Method Semantics
+
+| Method | Idempotent | Safe | Use For |
+|--------|-----------|------|---------|
+| GET | Yes | Yes | Retrieve resources |
+| POST | No | No | Create resources, trigger actions |
+| PUT | Yes | No | Full replacement of a resource |
+| PATCH | No* | No | Partial update of a resource |
+| DELETE | Yes | No | Remove a resource |
+
+*PATCH can be made idempotent with proper implementation
+
+### Status Code Reference
+
+```
+# Success
+200 OK                    — GET, PUT, PATCH (with response body)
+201 Created               — POST (include Location header)
+204 No Content            — DELETE, PUT (no response body)
+
+# Client Errors
+400 Bad Request           — Validation failure, malformed JSON
+401 Unauthorized          — Missing or invalid authentication
+403 Forbidden             — Authenticated but not authorized
+404 Not Found             — Resource doesn't exist
+409 Conflict              — Duplicate entry, state conflict
+422 Unprocessable Entity  — Semantically invalid (valid JSON, bad data)
+429 Too Many Requests     — Rate limit exceeded
+
+# Server Errors
+500 Internal Server Error — Unexpected failure (never expose details)
+502 Bad Gateway           — Upstream service failed
+503 Service Unavailable   — Temporary overload, include Retry-After
+```
+
+### Common Mistakes
+
+```
+# BAD: 200 for everything
+{ "status": 200, "success": false, "error": "Not found" }
+
+# GOOD: Use HTTP status codes semantically
+HTTP/1.1 404 Not Found
+{ "error": { "code": "not_found", "message": "User not found" } }
+
+# BAD: 500 for validation errors
+# GOOD: 400 or 422 with field-level details
+
+# BAD: 200 for created resources
+# GOOD: 201 with Location header
+HTTP/1.1 201 Created
+Location: /api/v1/users/abc-123
+```
+
+## Response Format
+
+### Success Response
+
+```json
+{
+  "data": {
+    "id": "abc-123",
+    "email": "alice@example.com",
+    "name": "Alice",
+    "created_at": "2025-01-15T10:30:00Z"
+  }
+}
+```
+
+### Collection Response (with Pagination)
+
+```json
+{
+  "data": [
+    { "id": "abc-123", "name": "Alice" },
+    { "id": "def-456", "name": "Bob" }
+  ],
+  "meta": {
+    "total": 142,
+    "page": 1,
+    "per_page": 20,
+    "total_pages": 8
+  },
+  "links": {
+    "self": "/api/v1/users?page=1&per_page=20",
+    "next": "/api/v1/users?page=2&per_page=20",
+    "last": "/api/v1/users?page=8&per_page=20"
+  }
+}
+```
+
+### Error Response
+
+```json
+{
+  "error": {
+    "code": "validation_error",
+    "message": "Request validation failed",
+    "details": [
+      {
+        "field": "email",
+        "message": "Must be a valid email address",
+        "code": "invalid_format"
+      },
+      {
+        "field": "age",
+        "message": "Must be between 0 and 150",
+        "code": "out_of_range"
+      }
+    ]
+  }
+}
+```
+
+### Response Envelope Variants
+
+```typescript
+// Option A: Envelope with data wrapper (recommended for public APIs)
+interface ApiResponse<T> {
+  data: T;
+  meta?: PaginationMeta;
+  links?: PaginationLinks;
+}
+
+interface ApiError {
+  error: {
+    code: string;
+    message: string;
+    details?: FieldError[];
+  };
+}
+
+// Option B: Flat response (simpler, common for internal APIs)
+// Success: just return the resource directly
+// Error: return error object
+// Distinguish by HTTP status code
+```
+
+## Pagination
+
+### Offset-Based (Simple)
+
+```
+GET /api/v1/users?page=2&per_page=20
+
+# Implementation
+SELECT * FROM users
+ORDER BY created_at DESC
+LIMIT 20 OFFSET 20;
+```
+
+**Pros:** Easy to implement, supports "jump to page N"
+**Cons:** Slow on large offsets (OFFSET 100000), inconsistent with concurrent inserts
+
+### Cursor-Based (Scalable)
+
+```
+GET /api/v1/users?cursor=eyJpZCI6MTIzfQ&limit=20
+
+# Implementation
+SELECT * FROM users
+WHERE id > :cursor_id
+ORDER BY id ASC
+LIMIT 21;  -- fetch one extra to determine has_next
+```
+
+```json
+{
+  "data": [...],
+  "meta": {
+    "has_next": true,
+    "next_cursor": "eyJpZCI6MTQzfQ"
+  }
+}
+```
+
+**Pros:** Consistent performance regardless of position, stable with concurrent inserts
+**Cons:** Cannot jump to arbitrary page, cursor is opaque
+
+### When to Use Which
+
+| Use Case | Pagination Type |
+|----------|----------------|
+| Admin dashboards, small datasets (<10K) | Offset |
+| Infinite scroll, feeds, large datasets | Cursor |
+| Public APIs | Cursor (default) with offset (optional) |
+| Search results | Offset (users expect page numbers) |
+
+## Filtering, Sorting, and Search
+
+### Filtering
+
+```
+# Simple equality
+GET /api/v1/orders?status=active&customer_id=abc-123
+
+# Comparison operators (use bracket notation)
+GET /api/v1/products?price[gte]=10&price[lte]=100
+GET /api/v1/orders?created_at[after]=2025-01-01
+
+# Multiple values (comma-separated)
+GET /api/v1/products?category=electronics,clothing
+
+# Nested fields (dot notation)
+GET /api/v1/orders?customer.country=US
+```
+
+### Sorting
+
+```
+# Single field (prefix - for descending)
+GET /api/v1/products?sort=-created_at
+
+# Multiple fields (comma-separated)
+GET /api/v1/products?sort=-featured,price,-created_at
+```
+
+### Full-Text Search
+
+```
+# Search query parameter
+GET /api/v1/products?q=wireless+headphones
+
+# Field-specific search
+GET /api/v1/users?email=alice
+```
+
+### Sparse Fieldsets
+
+```
+# Return only specified fields (reduces payload)
+GET /api/v1/users?fields=id,name,email
+GET /api/v1/orders?fields=id,total,status&include=customer.name
+```
+
+## Authentication and Authorization
+
+### Token-Based Auth
+
+```
+# Bearer token in Authorization header
+GET /api/v1/users
+Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
+
+# API key (for server-to-server)
+GET /api/v1/data
+X-API-Key: sk_live_abc123
+```
+
+### Authorization Patterns
+
+```typescript
+// Resource-level: check ownership
+app.get("/api/v1/orders/:id", async (req, res) => {
+  const order = await Order.findById(req.params.id);
+  if (!order) return res.status(404).json({ error: { code: "not_found" } });
+  if (order.userId !== req.user.id) return res.status(403).json({ error: { code: "forbidden" } });
+  return res.json({ data: order });
+});
+
+// Role-based: check permissions
+app.delete("/api/v1/users/:id", requireRole("admin"), async (req, res) => {
+  await User.delete(req.params.id);
+  return res.status(204).send();
+});
+```
+
+## Rate Limiting
+
+### Headers
+
+```
+HTTP/1.1 200 OK
+X-RateLimit-Limit: 100
+X-RateLimit-Remaining: 95
+X-RateLimit-Reset: 1640000000
+
+# When exceeded
+HTTP/1.1 429 Too Many Requests
+Retry-After: 60
+{
+  "error": {
+    "code": "rate_limit_exceeded",
+    "message": "Rate limit exceeded. Try again in 60 seconds."
+  }
+}
+```
+
+### Rate Limit Tiers
+
+| Tier | Limit | Window | Use Case |
+|------|-------|--------|----------|
+| Anonymous | 30/min | Per IP | Public endpoints |
+| Authenticated | 100/min | Per user | Standard API access |
+| Premium | 1000/min | Per API key | Paid API plans |
+| Internal | 10000/min | Per service | Service-to-service |
+
+## Versioning
+
+### URL Path Versioning (Recommended)
+
+```
+/api/v1/users
+/api/v2/users
+```
+
+**Pros:** Explicit, easy to route, cacheable
+**Cons:** URL changes between versions
+
+### Header Versioning
+
+```
+GET /api/users
+Accept: application/vnd.myapp.v2+json
+```
+
+**Pros:** Clean URLs
+**Cons:** Harder to test, easy to forget
+
+### Versioning Strategy
+
+```
+1. Start with /api/v1/ — don't version until you need to
+2. Maintain at most 2 active versions (current + previous)
+3. Deprecation timeline:
+   - Announce deprecation (6 months notice for public APIs)
+   - Add Sunset header: Sunset: Sat, 01 Jan 2026 00:00:00 GMT
+   - Return 410 Gone after sunset date
+4. Non-breaking changes don't need a new version:
+   - Adding new fields to responses
+   - Adding new optional query parameters
+   - Adding new endpoints
+5. Breaking changes require a new version:
+   - Removing or renaming fields
+   - Changing field types
+   - Changing URL structure
+   - Changing authentication method
+```
+
+## Implementation Patterns
+
+### TypeScript (Next.js API Route)
+
+```typescript
+import { z } from "zod";
+import { NextRequest, NextResponse } from "next/server";
+
+const createUserSchema = z.object({
+  email: z.string().email(),
+  name: z.string().min(1).max(100),
+});
+
+export async function POST(req: NextRequest) {
+  const body = await req.json();
+  const parsed = createUserSchema.safeParse(body);
+
+  if (!parsed.success) {
+    return NextResponse.json({
+      error: {
+        code: "validation_error",
+        message: "Request validation failed",
+        details: parsed.error.issues.map(i => ({
+          field: i.path.join("."),
+          message: i.message,
+          code: i.code,
+        })),
+      },
+    }, { status: 422 });
+  }
+
+  const user = await createUser(parsed.data);
+
+  return NextResponse.json(
+    { data: user },
+    {
+      status: 201,
+      headers: { Location: `/api/v1/users/${user.id}` },
+    },
+  );
+}
+```
+
+### Python (Django REST Framework)
+
+```python
+from rest_framework import serializers, viewsets, status
+from rest_framework.response import Response
+
+class CreateUserSerializer(serializers.Serializer):
+    email = serializers.EmailField()
+    name = serializers.CharField(max_length=100)
+
+class UserSerializer(serializers.ModelSerializer):
+    class Meta:
+        model = User
+        fields = ["id", "email", "name", "created_at"]
+
+class UserViewSet(viewsets.ModelViewSet):
+    serializer_class = UserSerializer
+    permission_classes = [IsAuthenticated]
+
+    def get_serializer_class(self):
+        if self.action == "create":
+            return CreateUserSerializer
+        return UserSerializer
+
+    def create(self, request):
+        serializer = CreateUserSerializer(data=request.data)
+        serializer.is_valid(raise_exception=True)
+        user = UserService.create(**serializer.validated_data)
+        return Response(
+            {"data": UserSerializer(user).data},
+            status=status.HTTP_201_CREATED,
+            headers={"Location": f"/api/v1/users/{user.id}"},
+        )
+```
+
+### Go (net/http)
+
+```go
+func (h *UserHandler) CreateUser(w http.ResponseWriter, r *http.Request) {
+    var req CreateUserRequest
+    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
+        writeError(w, http.StatusBadRequest, "invalid_json", "Invalid request body")
+        return
+    }
+
+    if err := req.Validate(); err != nil {
+        writeError(w, http.StatusUnprocessableEntity, "validation_error", err.Error())
+        return
+    }
+
+    user, err := h.service.Create(r.Context(), req)
+    if err != nil {
+        switch {
+        case errors.Is(err, domain.ErrEmailTaken):
+            writeError(w, http.StatusConflict, "email_taken", "Email already registered")
+        default:
+            writeError(w, http.StatusInternalServerError, "internal_error", "Internal error")
+        }
+        return
+    }
+
+    w.Header().Set("Location", fmt.Sprintf("/api/v1/users/%s", user.ID))
+    writeJSON(w, http.StatusCreated, map[string]any{"data": user})
+}
+```
+
+## API Design Checklist
+
+Before shipping a new endpoint:
+
+- [ ] Resource URL follows naming conventions (plural, kebab-case, no verbs)
+- [ ] Correct HTTP method used (GET for reads, POST for creates, etc.)
+- [ ] Appropriate status codes returned (not 200 for everything)
+- [ ] Input validated with schema (Zod, Pydantic, Bean Validation)
+- [ ] Error responses follow standard format with codes and messages
+- [ ] Pagination implemented for list endpoints (cursor or offset)
+- [ ] Authentication required (or explicitly marked as public)
+- [ ] Authorization checked (user can only access their own resources)
+- [ ] Rate limiting configured
+- [ ] Response does not leak internal details (stack traces, SQL errors)
+- [ ] Consistent naming with existing endpoints (camelCase vs snake_case)
+- [ ] Documented (OpenAPI/Swagger spec updated)