# 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`