72 lines
2.3 KiB
Markdown
72 lines
2.3 KiB
Markdown
|
# Sozsoft Platform - Claude Instructions
|
||
|
|
|
||
|
|
This file provides Claude-specific operating rules for this repository.
|
||
|
|
Primary source of truth for platform behavior is:
|
||
|
|
|
||
|
|
- `.github/instructions/ai.instructions.md`
|
||
|
|
|
||
|
|
If there is any conflict, follow `.github/instructions/ai.instructions.md`.
|
||
|
|
|
||
|
|
## Purpose
|
||
|
|
|
||
|
|
- Maximize delivery through runtime configuration.
|
||
|
|
- Minimize custom code.
|
||
|
|
- Preserve platform consistency, security, and tenant isolation.
|
||
|
|
|
||
|
|
Primary principle: Configuration first, code last.
|
||
|
|
|
||
|
|
## Mandatory Decision Order
|
||
|
|
|
||
|
|
For every request, evaluate and propose in this order:
|
||
|
|
|
||
|
|
1. Dynamic configuration with existing ListForm ecosystem
|
||
|
|
2. SQL Query Manager + Custom Endpoint
|
||
|
|
3. Dynamic Service
|
||
|
|
4. Code change (last resort, justification required)
|
||
|
|
|
||
|
|
## Non-Negotiable Rules
|
||
|
|
|
||
|
|
1. Do not propose new custom React component/page development for standard feature requests.
|
||
|
|
2. Build new screens using platform configuration mechanisms.
|
||
|
|
3. Every proposal must include tenant and permission design.
|
||
|
|
4. Never bypass platform authorization patterns.
|
||
|
|
5. Never hardcode secrets, tenant IDs, or connection strings.
|
||
|
|
|
||
|
|
Exception:
|
||
|
|
|
||
|
|
- Custom React/backend code is allowed only when the user explicitly requests implementation and configuration is insufficient.
|
||
|
|
- In such cases, explain why configuration-first options are not enough.
|
||
|
|
|
||
|
|
## Architecture Guardrails
|
||
|
|
|
||
|
|
- Backend: Respect ABP module boundaries and explicit, auditable permissions.
|
||
|
|
- Frontend: Use existing dynamic view infrastructure and metadata-driven behavior.
|
||
|
|
- Data: Use parameterized SQL patterns and enforce tenant-safe access.
|
||
|
|
|
||
|
|
## Dynamic Platform Expectations
|
||
|
|
|
||
|
|
- Menus and routes are database-driven.
|
||
|
|
- Dynamic List/Form/Component infrastructure is the default solution path.
|
||
|
|
- Keep route, menu, permission, and datasource mappings coherent.
|
||
|
|
|
||
|
|
## Security and Compliance
|
||
|
|
|
||
|
|
- Enforce RBAC and permission-driven visibility in all layers.
|
||
|
|
- Never output real credentials, tokens, keys, or secrets.
|
||
|
|
- Use placeholders in examples.
|
||
|
|
- Maintain tenant isolation in every query and action.
|
||
|
|
|
||
|
|
## Response Contract
|
||
|
|
|
||
|
|
When producing an implementation proposal, include:
|
||
|
|
|
||
|
|
1. Goal
|
||
|
|
2. Decision flow result (which step used)
|
||
|
|
3. Artifacts to configure
|
||
|
|
4. SQL/query/endpoint design (if needed)
|
||
|
|
5. Menu + route + component mapping
|
||
|
|
6. Permission and role mapping
|
||
|
|
7. Tenant isolation notes
|
||
|
|
8. Validation and test checklist
|
||
|
|
9. Rollback strategy
|