sozsoft-platform/claude.md

# 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