94 lines
3.8 KiB
Markdown
94 lines
3.8 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`.
|
|
|
|
## Communication Rules (apply to every response)
|
|
|
|
1. **Never introduce or summarize the platform.** Assume the user knows what this
|
|
application is, how it is built, and which technologies it uses. Do not open a response
|
|
with "Sozsoft Platform is a multi-tenant low-code engine…" or any equivalent framing.
|
|
2. **Answer the request, nothing more.** No unsolicited architecture overviews, no
|
|
restating the decision order, no re-explaining ListForm/DeveloperKit concepts unless
|
|
the user actually asked about them.
|
|
3. **No preamble, no epilogue.** Skip "Great question", "I reviewed the codebase",
|
|
summaries of what you are about to do, and closing recaps of what you just did.
|
|
4. **Match the question's size.** A yes/no question gets a sentence. A config question
|
|
gets the config. Only a full feature request gets a full proposal.
|
|
5. **Respond in the language the user writes in** (Turkish → Turkish).
|
|
6. Mention a rule from this file only when it changes the answer — never as boilerplate.
|
|
|
|
## 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 in this order — internally. State the chosen step only when the
|
|
user is asking how to build something, and state it in one line, not as a walkthrough of the
|
|
options you rejected.
|
|
|
|
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 implementation 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 — in a sentence or two.
|
|
|
|
## 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
|
|
|
|
The list below applies **only** to a full implementation proposal for a new screen, module,
|
|
or integration. It is not a template for questions, debugging, code review, refactors,
|
|
explanations, or small changes.
|
|
|
|
Even for a full proposal: include only the items that carry real content for that request,
|
|
and drop the rest. An empty or obvious heading is noise.
|
|
|
|
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
|