接入商品评论数据

.github/copilot-instructions.md

@@ -0,0 +1,111 @@
+# Copilot Instructions for This Repository
+
+## Project context
+
+This repository contains a multi-module mall system with admin-oriented database SQL organized by execution stage and business domain.
+For any task related to database changes, RPC, RLS, or admin data access, treat `docs/sql/README_EXECUTION_ORDER.md` as the authoritative execution and validation reference.
+
+## Core database rules
+
+1. Follow the required execution order for database changes:
+   - Schema / Migration first
+   - RLS second
+   - RPC last
+
+2. Never change the order to RPC -> RLS -> Schema.
+   RPC and RLS may depend on fields, indexes, or policies created in Schema.
+
+3. Soft delete is the default deletion standard.
+   Do not implement physical deletes unless the task explicitly requires it and the user confirms.
+   Prefer updating soft-delete fields such as:
+   - `deleted_at`
+   - `deleted_by`
+   - `restored_at`
+   - `restored_by`
+
+4. For delete-related RPC or SQL:
+   - do not use physical `DELETE` by default
+   - write `deleted_at` and `deleted_by`
+   - preserve auditability
+   - apply cascade soft delete when the existing design requires it
+
+5. For RLS-related work:
+   - assume soft-deleted rows should be filtered by default
+   - when appropriate, ensure policies include logic equivalent to `deleted_at IS NULL`
+   - do not weaken existing RLS rules without clearly explaining why
+
+6. For existing RPC/functions:
+   - prefer `CREATE OR REPLACE FUNCTION`
+   - avoid creating duplicate function variants unless versioning is explicitly required
+
+## Required working method
+
+1. Analyze first, edit second.
+   Before making changes, first inspect the relevant files and summarize:
+   - affected files
+   - dependencies
+   - execution order
+   - risks
+
+2. Limit the scope of changes.
+   Only modify the business domain and files directly related to the task.
+   Do not refactor unrelated modules.
+
+3. Do not invent schema details.
+   Before generating SQL or admin code, inspect the actual table definitions, RPC files, and RLS files already present in the repository.
+
+4. Preserve current naming and directory conventions.
+   Keep the existing staged SQL structure such as:
+   - `10_schema/**`
+   - `20_rls/**`
+   - `30_rpc/**`
+
+5. Keep admin-facing behavior consistent with current project conventions.
+   Do not silently break existing frontend call paths, parameter names, return structures, or pagination contracts.
+
+## Output requirements for Copilot responses
+
+For any non-trivial task, respond with:
+
+1. A short impact summary
+2. The list of files to change
+3. The implementation plan in the correct order
+4. The actual code/SQL changes
+5. A validation checklist
+6. Any risks, assumptions, or rollback notes
+
+## Validation requirements
+
+When a task changes database behavior, include verification steps for:
+
+- field existence
+- soft-delete index existence
+- RLS effectiveness
+- RPC behavior
+- whether deletion remains soft delete instead of physical delete
+- whether `deleted_at` / `deleted_by` are written correctly
+- whether required cascade soft delete behavior still works
+
+## SQL and Supabase safety rules
+
+1. Do not assume a SQL file has already been executed just because it exists in the repository.
+2. Do not assume a table is in `public` unless verified.
+3. If a task involves Supabase-exposed data access, consider RLS impact explicitly.
+4. If adding a new table or new admin data access path, mention whether RLS and policies also need to be added or updated.
+
+## Preferred behavior for complex tasks
+
+For large tasks, break the work into phases:
+
+1. inspect
+2. plan
+3. implement
+4. validate
+
+Do not jump straight into large-scale edits without first identifying dependencies.
+
+## Reference
+
+Primary reference for database execution order and validation:
+
+- `docs/sql/README_EXECUTION_ORDER.md`