112 lines
3.7 KiB
Markdown
112 lines
3.7 KiB
Markdown
# 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`
|