From 3baa7def6160d0c5ef6f5581c29c22bad62b321e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sedat=20=C3=96ZT=C3=9CRK?= <76204082+iamsedatozturk@users.noreply.github.com> Date: Wed, 25 Mar 2026 08:52:55 +0300 Subject: [PATCH] AI Instructions --- .github/instructions/ai.instructions.md | 711 ++++++++++++++++++ .github/instructions/list.instructions.md | 149 ++++ .../Seeds/LanguagesData.json | 4 +- claude.md | 71 ++ 4 files changed, 933 insertions(+), 2 deletions(-) create mode 100644 .github/instructions/ai.instructions.md create mode 100644 .github/instructions/list.instructions.md create mode 100644 claude.md diff --git a/.github/instructions/ai.instructions.md b/.github/instructions/ai.instructions.md new file mode 100644 index 0000000..5dc9f79 --- /dev/null +++ b/.github/instructions/ai.instructions.md @@ -0,0 +1,711 @@ +# Dynamic Low-Code Platform - AI Instruction and Operating Manual + +## 1. Purpose + +This document defines how AI should think, decide, and produce outputs for this platform. + +Primary objective: + +- Maximize delivery through runtime configuration. +- Minimize custom code. +- Preserve platform consistency, security, and tenant isolation. + +Primary principle: + +- Configuration first, code last. + +--- + +## 2. Platform Scope + +Core stack: + +- Backend: C# .NET 9 + ABP 9.x +- Frontend: React 18 + DevExtreme +- Database: SQL Server (dynamic datasource support) +- Cache: Redis +- Background jobs: Hangfire + ABP Background Workers + +System nature: + +- Runtime configurable application engine +- Multi-tenant SaaS foundation +- Low-code / no-code first + +--- + +## 3. 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 policy: + +- Code-level React or backend development can be considered only if user explicitly requests code implementation and configuration path is insufficient. +- If exception is required, AI must explain why configuration-based options are not enough. + +--- + +## 4. Decision Flow (Mandatory) + +For every request, apply 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) + +--- + +## 5. Architecture Guardrails + +Backend (ABP): + +- Respect modular boundaries. +- Prefer application services over ad-hoc endpoints. +- Keep permissions explicit and auditable. + +Frontend (React + DevExtreme): + +- Use existing dynamic view infrastructure. +- Keep component behavior metadata-driven. +- Preserve route, menu, and permission coherence. + +Data: + +- SQL-first for shaping, filtering, aggregation, reporting. +- Parameterized query patterns only. +- Ensure tenant-safe data access. + +--- + +## 6. Dynamic Menu and Routing + +- Menus are database driven. +- Routes are generated/managed dynamically. +- Each menu item should map to: + - Target component mode + - Data source or query context + - Endpoint/service target + - Permission contract + +--- + +## 7. Dynamic List System + +Driven by: + +- ListForm +- ListFormFields +- ListFormCustomization (UserUiFilter, GridState, ServerJoin, ServerWhere) +- ListFormImport and ListFormImportExecute +- ListFormJsonRow operations + +Capabilities: + +- Dynamic columns, command column, banded columns +- Permission-aware visibility and action rendering +- Rich filtering, sorting, grouping, paging, searching +- Dynamic toolbar actions and URL/dialog/script command flows +- Lookup sources: + - StaticData + - Query + - WebService +- Cascading lookup parent-child behavior +- Dynamic validation, editor options, editor scripts +- Conditional formatting and style injection +- Grid state save/load/reset +- User filter save/apply/delete flows +- Import manager and export flows (xlsx, csv, pdf) +- SubForm integration from selected row context +- Remote operations and dynamic datasource rebinding + +Supported editor types: + +- dxAutocomplete +- dxCalendar +- dxCheckBox +- dxColorBox +- dxDateBox +- dxDateRangeBox +- dxDropDownBox +- dxGridBox +- dxHtmlEditor +- dxLookup +- dxNumberBox +- dxRadioGroup +- dxRangeSlider +- dxSelectBox +- dxSlider +- dxSwitch +- dxTagBox +- dxTextArea +- dxTextBox + +--- + +## 8. Dynamic Form System + +- DevExtreme Form-based runtime field generation +- Metadata-driven item groups/tabs +- Validation and conditional behavior +- CRUD integration +- Default value and runtime script handling +- Lookup-enabled field model + +--- + +## 9. Dynamic UI Components + +Supported component families: + +- DataGrid +- PivotGrid +- Form +- Chart +- Scheduler +- Gantt +- TreeList / Tree view +- SubForm tabs (List, Tree, Gantt, Scheduler, Form, Chart) +- Widget Group (dashboard KPI cards) + +Runtime UI capabilities: + +- Per-list layout switching: + - Grid + - Pivot + - Tree + - Chart + - Gantt + - Scheduler +- Per-user layout persistence +- Lazy loading and view preloading +- Shared dynamic datasource pipeline across layouts +- Shared filter/search/deep-link behavior +- Runtime refresh and query rebind +- Runtime state lifecycle: + - Save state + - Load state + - Reset state +- Runtime import/export actions from UI flows +- Popup and fullscreen editing scenarios +- SubForm relation-aware context propagation and tab navigation + +--- + +## 10. Dynamic Component Development Policy + +Allowed approach: + +- Configure and bind existing dynamic component infrastructure. + +Disallowed by default: + +- New custom React pages/components for normal business requirements. + +If user requests custom code explicitly: + +- Provide a warning that low-code path is preferred. +- Offer configuration-first alternative first. + +--- + +## 11. Integrations + +Notification channels: + +- Sms +- Mail +- Rocket +- Desktop +- UiActivity +- UiToast +- WhatsApp +- Telegram + +Sender module: + +- Email (ABP Emailing + Amazon SES) +- SMS (ABP Sms + Posta Guvercini) +- Rocket.Chat (HTTP API) +- WhatsApp (HTTP API, template-based) + +Notification routing model: + +- Type + Channel routing +- Recipient targeting: + - All + - User + - Role + - OrganizationUnit + - Custom + +MailQueue: + +- Template-based body generation +- Attachment lifecycle +- File outputs (PDF, XLS, TXT) +- Queue execution and logging + +AI workflow integration: + +- n8n webhook chat endpoint +- LangChain agent flow + memory window +- Gemini chat model connector + +--- + +## 12. Background Processing + +Supported engines: + +- Hangfire +- ABP Background Workers + +Typical use cases: + +- Scheduled SQL execution +- Notification dispatching +- Email and integration automation + +--- + +## 13. Security and Compliance Rules + +- Enforce RBAC and permission-driven visibility at all layers. +- Always include permission definitions in feature design. +- Never output real credentials, tokens, keys, or secrets. +- Use placeholders in examples. +- Maintain tenant isolation in every query and action. + +--- + +## 14. Required AI Output Contract + +For each implementation proposal, AI output must 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 + +--- + +## 15. Quality Gate Checklist + +Before finalizing any answer, verify all: + +- No unnecessary custom code suggestion +- No forbidden React component proposal +- Tenant awareness is explicit +- Permission strategy is explicit +- Menu-route binding is explicit +- Data safety and SQL parameterization considered +- Background processing considered when async/scheduled + +--- + +## 16. Anti-Patterns (Do Not Suggest) + +- Writing controllers for flows already covered by dynamic infrastructure +- Hardcoded endpoint mapping without permission model +- Static UI screens disconnected from list/menu/route model +- Direct non-tenant-safe query patterns +- Copying secrets into examples + +--- + +## 17. Example Request Types AI Must Handle + +- Create customer list screen +- Build purchase module +- Create dashboard with charts +- Generate reporting screen +- Add approval workflow +- Add integration-triggered notification process + +--- + +## 18. Escalation Strategy + +When configuration cannot satisfy requirement: + +1. Try SQL-based design +2. Try Custom Endpoint +3. Try Dynamic Service +4. Propose minimal code change with explicit justification + +--- + +## 19. Final Rule + +This platform is not a traditional code-first app. + +It is a runtime configurable low-code engine. + +AI must optimize for platform consistency, configurability, auditability, and safe scale. + +--- + +## 20. Request Classification Matrix + +Before proposing any solution, classify the request into one of these classes: + +Class A - Pure configuration: + +- Menu, route, list/form fields, validation, permissions, layout, filters +- Expected output: configuration-first plan only + +Class B - Configuration + SQL: + +- Reporting, complex filtering, aggregation, lookup dependencies +- Expected output: configuration + SQL + endpoint mapping + +Class C - Configuration + Integration: + +- Notification, sender, queue, webhook, workflow automation +- Expected output: configuration + integration contract + retry/fallback notes + +Class D - Escalated code path: + +- Only when A/B/C cannot satisfy requirement +- Expected output: explicit justification, minimal scope code plan, rollback plan + +--- + +## 21. Response Playbooks + +### 21.1 New Screen Playbook + +1. Define business objective and actor roles. +2. Define ListForm and ListFormFields structure. +3. Define menu entry and route mapping. +4. Define permissions (R/C/U/D/E) and role mapping. +5. Define datasource and query strategy. +6. Define runtime filters, lookup, validations. +7. Define import/export and state requirements. +8. Define acceptance checklist. + +### 21.2 Workflow/Approval Playbook + +1. Define states and transition rules. +2. Define transition permissions by role. +3. Define transition side-effects (notification, queue, endpoint call). +4. Define audit log and failure handling. +5. Define rollback/compensation behavior. + +### 21.3 Report/Dashboard Playbook + +1. Define KPIs and dimensions. +2. Define SQL shaping and aggregation logic. +3. Define chart/pivot configuration. +4. Define date/tenant filters. +5. Define export needs and performance constraints. + +--- + +## 22. Mandatory Acceptance Criteria Template + +Every final proposal must include a clear, testable acceptance list: + +1. Feature can be enabled via configuration. +2. Tenant boundaries are preserved. +3. Required permissions block unauthorized access. +4. Menu-route-screen path is navigable. +5. Data operations are parameterized and safe. +6. Runtime filters and state behaviors work. +7. Integration events (if any) are observable and retry-safe. +8. No unnecessary custom code introduced. + +--- + +## 23. AI Output Templates + +### 23.1 Configuration-only Output Template + +1. Goal +2. Configuration artifacts +3. Menu/route mapping +4. Permission mapping +5. Validation checklist + +### 23.2 Configuration + SQL Output Template + +1. Goal +2. Required configuration artifacts +3. SQL design (inputs, outputs, filter parameters) +4. Endpoint/service mapping +5. Security and tenant notes +6. Validation checklist + +### 23.3 Escalated Code Output Template + +1. Why configuration is insufficient +2. Minimal code scope +3. Compatibility with existing dynamic architecture +4. Migration and rollback plan +5. Risk and test plan + +--- + +## 24. Performance and Scalability Rules + +- Prefer server-side filtering/sorting/paging for large datasets. +- Avoid unbounded result sets in dynamic queries. +- Use indexing-aware query patterns for reporting screens. +- Keep chart/pivot queries aggregation-focused. +- Separate interactive screen queries from heavy export queries. +- Use background jobs for long-running batch operations. + +--- + +## 25. Observability and Audit Rules + +- Log key operations at list/form/integration boundaries. +- Preserve who/when/what audit metadata for critical changes. +- Capture integration failures with retry reason and payload context. +- Keep user-facing messages simple, logs detailed. +- Ensure state changes are diagnosable for support teams. + +--- + +## 26. Error Handling Policy + +- Never expose raw secrets or internal stack details to end users. +- Return actionable, localized, user-level messages. +- Keep technical diagnostics in logs. +- For integration failures: + - Retry where safe + - Record dead-letter/failure state + - Provide manual replay strategy when needed + +--- + +## 27. Change Management Policy + +- Prefer additive changes over breaking modifications. +- Keep existing ListForm contracts backward compatible where possible. +- Document behavior changes in rollout notes. +- For destructive changes, require explicit migration path. + +--- + +## 28. Definition of Done for AI Proposals + +A proposal is complete only if all are present: + +1. Decision flow step selected and justified. +2. Configuration artifacts clearly listed. +3. Permission and tenant design included. +4. Menu-route-component mapping included. +5. Validation checklist included. +6. Risk/rollback notes included. + +--- + +## 29. Prohibited Suggestion Set + +AI must not suggest: + +- Quick custom React page as first solution +- Hardcoded tenant ids or environment secrets +- Direct SQL string concatenation with user input +- Endpoint exposure without permission definitions +- Bypassing platform menu-route model for business screens + +--- + +## 30. Final Governance Statement + +This manual is authoritative for AI behavior in this repository. + +When in doubt, AI must choose the path that preserves: + +- Low-code configurability +- Tenant safety +- Permission correctness +- Operational auditability +- Long-term maintainability + +--- + +## 31. Seeder-Driven Low-Code Development Guide (Authoritative) + +AI must learn and teach implementation flow primarily from these seed assets: + +- api/src/Sozsoft.Platform.DbMigrator/Seeds/ListFormSeeder_Saas.cs +- api/src/Sozsoft.Platform.DbMigrator/Seeds/MenusData.json +- api/src/Sozsoft.Platform.DbMigrator/Seeds/PermissionsData.json +- api/src/Sozsoft.Platform.DbMigrator/Seeds/HostData.json +- api/src/Sozsoft.Platform.DbMigrator/Seeds/LanguagesData.json + +If user asks "how to add a new module/screen", AI must answer with this exact operational sequence. + +### 31.1 Step 1 - Create ListForm definition + +Define a new `ListForm` with at least: + +- `ListFormCode`, `Name`, `Title` +- `DataSourceCode` +- `SelectCommandType` + `SelectCommand` +- `KeyFieldName` + `KeyFieldDbSourceType` +- `PermissionJson` (create/read/update/delete/export/import/note) +- `EditingOptionJson` + `EditingFormJson` +- `FilterRowJson`, `HeaderFilterJson`, `SearchPanelJson`, `GroupPanelJson` +- `SelectionJson`, `ColumnOptionJson`, `PagerOptionJson` +- `InsertServiceAddress`, `UpdateServiceAddress`, `DeleteCommand` + +For parent-child scenarios, define `SubFormsJson` relation mapping (ParentFieldName -> ChildFieldName, DbType). + +### 31.2 Step 2 - Create ListFormFields + +For each field, define runtime behavior through `ListFormField` records: + +- Data binding: field name, db type, source +- UI behavior: visibility, order, width, grouping, fixed/band settings +- Editing behavior: editor type (`dxTextBox`, `dxSelectBox`, `dxNumberBox`, etc.), required, options +- Lookup behavior: data source type, display/value members, cascade rules +- Validation rules and default values +- Command/action columns where needed + +AI must prioritize metadata-based field behavior instead of suggesting custom React forms. + +### 31.3 Step 3 - Add menu and route mapping + +From `MenusData.json` patterns, AI must define both: + +- `Routes` entry: + - `key`, `path`, `componentPath`, `routeType`, `authority` +- `Menus` entry: + - `ParentCode`, `Code`, `DisplayName`, `Url`, `Icon`, `RequiredPermissionName`, `Order` + +For dynamic list screens, base route pattern is: + +- `/admin/list/{ListFormCode}` + +AI must ensure menu URL and route path point to same screen contract. + +### 31.4 Step 4 - Add permissions + +From `PermissionsData.json` patterns, AI must define: + +- Permission group (if missing) +- Permission definitions for feature root and actions +- Menu permission binding (`RequiredPermissionName`) + +Minimum action set suggestion: + +- `.Default` +- `.Create` +- `.Update` +- `.Delete` +- `.Export` +- `.Import` +- `.Note` + +AI must never propose menu/route without permission contract. + +### 31.5 Step 5 - Add settings/integration dependencies + +From `HostData.json` patterns, AI must define required settings when feature depends on external services: + +- Sender credentials and endpoints (sms/mail/whatsapp/rocket) +- AiBot integration endpoint and activation state +- Feature-specific setting keys, providers, encryption flags + +If integration required and setting missing, AI must explicitly add "blocking prerequisite" note. + +### 31.6 Step 6 - Data and service contract + +AI must produce one of: + +- Direct table/view select command +- Parameterized SQL via managed query +- Custom endpoint / dynamic service + +AI must include tenant-safe filters and avoid string concatenation. + +### 31.7 Step 7 - Delivery checklist + +For every new low-code feature, AI output must list: + +1. New `ListForm` code and purpose +2. `ListFormField` set (critical columns/editors/lookups) +3. Route record +4. Menu record +5. Permission records +6. Required settings/integrations +7. Validation and rollback notes + +If this 7-item list is incomplete, proposal is not accepted. + +### 31.8 AI response style for implementation requests + +When user asks for a screen/module, AI must answer in this order: + +1. Decision flow class (A/B/C/D) +2. Seeder-style artifacts to add (ListForm, Fields, Menu, Route, Permission, Setting) +3. If needed, SQL/endpoint contract +4. Test and rollback checklist + +AI should produce practical, copy-adaptable artifact definitions and avoid abstract-only explanations. + +--- + +## 32. Mandatory Default Behaviors (Do Not Ask Repeatedly) + +The following defaults are mandatory unless user explicitly overrides them. + +### 32.1 SQL Table Designer default column behavior + +When user requests creating a table and only specifies business columns (for example `FullName`, `Phone`), AI must still ensure platform-standard technical columns are included by default in SQL Query Manager table design flow: + +- `TenantId` (multi-tenant compatibility) +- Full audited set: + - `Id` + - `CreationTime` + - `CreatorId` + - `LastModificationTime` + - `LastModifierId` + - `IsDeleted` + - `DeletionTime` + - `DeleterId` + +Rules: + +- Do not require user to explicitly request these columns each time. +- If user explicitly says "no tenant" or "no audit", then respect that override. +- Primary key strategy must remain compatible with existing index/key policy. + +### 32.2 Wizard menu parent fallback behavior + +When creating menu via Wizard/ListForm and user does not explicitly specify parent menu: + +- Do not auto-place under `Definitions` by default. +- Create (or use) a dedicated new top-level parent menu for that feature/module. +- Assign top-level menu `Order` as next available order (`max(Order) + 1`) among root menus. +- Place the generated list/menu item under this newly created parent. + +Rules: + +- `Definitions` can be used only when user explicitly selects it. +- Permission contract must be created/bound for both parent and child menu items. +- Route/menu consistency remains mandatory (`Url` and screen contract must match). + +### 32.3 AI enforcement requirement + +AI must proactively apply these defaults in: + +- implementation proposals, +- code/seed changes, +- migration and wizard behavior recommendations. + +If AI output omits these defaults without explicit user override, output is non-compliant. diff --git a/.github/instructions/list.instructions.md b/.github/instructions/list.instructions.md new file mode 100644 index 0000000..3e65f7d --- /dev/null +++ b/.github/instructions/list.instructions.md @@ -0,0 +1,149 @@ + +# Sozsoft Platform Module Implementation Rules & Instructions + +## Purpose +This document summarizes the rules, standards, and step-by-step instructions for implementing any module (e.g., CRM, MRP, HR) with a sample list (e.g., Opportunity, Order) in the Sozsoft Platform. Replace all placeholders (e.g., {Modul}, {Liste}, {Entity}) with your actual module, list, or entity names. Use as a reference for future development and as a prompt guide for similar tasks. + +--- + + +## General Principles +- **Configuration First:** Always prefer platform configuration (menus, permissions, forms, localization) over custom code. +- **Modularization:** Each module (e.g., {Modul}) must have its own seeder, permission group, and localization entries. +- **Naming Conventions:** + - Table names: `{Modul}_T_{Entity}` (e.g., `Mrp_T_Order`) + - Menu/permission keys: `App.{Modul}`, `App.{Modul}.{Liste}` +- **Tenant Isolation:** All data, forms, and permissions must be tenant-aware. +- **Localization:** Every menu, list, and field must have a corresponding entry in `LanguagesData.json`. +- **No Redundant Code:** Avoid duplicating permission grants or seeding logic across modules. +- **SeedConsts Rule:** For every new module/entity, add a constant to `SeedConsts` (e.g., `public static class {Modul}` and `public const string {Liste}`) if it does not already exist. Never duplicate existing constants. +- **DeleteCommand Rule:** In all `ListFormSeeder_{Modul}.cs` files, the `DeleteCommand` property **must** use the `DefaultDeleteCommand` function, e.g., `DeleteCommand = DefaultDeleteCommand("{TabloAdı}")`. Never use a raw SQL string directly for `DeleteCommand`. + +--- + +## Special File Handling Rules + +- **MenusData.json:** + - Never modify the `Routes` section directly. Only `MenuGroups` and `Menus` sections can be changed for menu additions or updates. All menu additions must use the platform's configuration mechanisms or be added to `MenuGroups` and `Menus` as required by platform design. + +- **LanguagesData.json:** + - When adding a new key, always check if the key already exists. Only add the key if it does not exist to prevent duplicates. + +--- + +## File-by-File Change Summary + + +### 1. MenusData.json +- **{Modul} menu** added as a top-level menu with `ShortName: {Modul}`. +- **{Liste}** added as a child menu under {Modul}. + +### 2. PermissionsData.json +- **{Modul} permissions** grouped under `App.{Modul}`. +- **{Liste} permissions** nested under {Modul} group. + +### 3. ListFormSeeder_Administration.cs +- **Removed** {Liste} seeding logic (moved to {Modul} seeder). + +### 4. ListFormSeeder_{Modul}.cs +- **Created** new seeder file for {Modul}. +- **Seeds** {Liste} list-form, referencing `{Modul}_T_{Entity}`. + +### 5. SqlTables.sql +- **Renamed** {Liste} table to `{Modul}_T_{Entity}`. +- **Updated** all related constraints and references. + +### 6. PlatformIdentityDataSeeder.cs +- **Removed** redundant {Modul} permission grant logic (now handled by PermissionsData.json). + +### 7. LanguagesData.json +- **Added** localization entries for: + - {Modul} menu and {Liste} list + - {Liste} list fields (e.g., `FullName`, `Phone`) + +--- + +## Step-by-Step Instructions (Prompt Examples) + + +### 1. Add a New Module (e.g., {Modul}) +``` +Yeni bir modül ekle (ör: {Modul}): +- MenusData.json'a kök menü olarak ekle +- PermissionsData.json'da ayrı bir PermissionGroup oluştur +- ListFormSeeder_{Modul}.cs dosyası oluştur ve list-form seed'ini buraya taşı +- SqlTables.sql'de tabloyu {Modul}_T_{Entity} olarak adlandır +- LanguagesData.json'a menü, liste ve alan çevirilerini ekle +``` + +### 2. Add a New List Under a Module +``` +Yeni bir liste ekle (ör: {Liste}): +- {Modul} ana menüsünün altına ekle +- ListFormSeeder_{Modul}.cs dosyasına seed kodunu ekle +- SqlTables.sql'de tabloyu {Modul}_T_{Entity} olarak oluştur +- PermissionsData.json'da ilgili izinleri {Modul} grubuna ekle +- LanguagesData.json'a liste ve alan çevirilerini ekle +``` + +### 3. Enforce Tenant Isolation and Full Audit +``` +Tablo ve list-form için tenant izolasyonu ve full-audit alanlarını ekle: +- Tabloya TenantId, CreationTime, CreatorId, LastModificationTime, LastModifierId, IsDeleted, DeleterId, DeletionTime alanlarını ekle +- List-form seed'inde tenant-aware ayarları kontrol et +``` + + +### 4. Add/Update Localization +``` +Yeni menü, liste veya alan eklediğinde LanguagesData.json'a şu şekilde ekle: +- App.{Modul} +- App.{Modul}.{Liste} +- App.Listform.ListformField.{Alan} +``` + +### 5. SeedConsts and DeleteCommand Rules +``` +- SeedConsts.cs dosyasına, yeni modül veya entity için (ör: public static class {Modul} ve altında public const string {Liste}) sabit ekle. Eğer zaten varsa tekrar ekleme. +- ListFormSeeder_{Modul}.cs dosyalarında DeleteCommand satırı **her zaman** DefaultDeleteCommand fonksiyonu ile olmalı: + DeleteCommand = DefaultDeleteCommand("{TabloAdı}") +- DeleteCommand'da doğrudan SQL stringi **kullanma**. +``` + +### 5. Remove Redundant or Incorrect Code +``` +- Farklı modüllerde aynı izin veya seed kodu varsa, sadece ilgili modülde bırak +- PlatformIdentityDataSeeder.cs'de Permission grant kodunu kaldır, PermissionsData.json'dan yönet +``` + +--- + + +## Validation Checklist +- [ ] Menü ve izinler doğru hiyerarşide mi? +- [ ] List-form seed'leri doğru modül dosyasında mı? +- [ ] Tablo isimleri ve referansları standartlara uygun mu? (örn: {Modul}_T_{Entity}) +- [ ] LanguagesData.json'da tüm yeni menü, liste ve alanlar var mı? +- [ ] Redundant kod veya izin grant'ı var mı? +- [ ] Seed ve migration sonrası UI'da çeviriler doğru görünüyor mu? +- [ ] SeedConsts.cs dosyasında ilgili sabitler var mı, tekrar eklenmemiş mi? +- [ ] ListFormSeeder dosyalarında DeleteCommand satırı DefaultDeleteCommand fonksiyonu ile mi atanmış? + +--- + +## Rollback Strategy +- Değişiklikleri modül bazında geri al (örn: sadece {Modul} ile ilgili dosyaları revert et) +- JSON dosyalarında eski anahtarları ve çevirileri sil +- Seeder ve migration dosyalarını eski haline getir + +--- + +## Quick Prompts for Future Use +- "Yeni bir modül ekle ve tüm standartlara göre yapılandır." +- "Yeni bir liste ekle, tenant izolasyonu ve çevirileriyle birlikte." +- "Mevcut bir modülde eksik olan çeviri veya izinleri tamamla." +- "Tüm {Modul} ile ilgili seed ve izinleri modüler yapıya uygun şekilde güncelle." + +--- + +> **Not:** Tüm işlemlerden sonra seed'leri çalıştırıp UI'da menü ve çevirileri kontrol etmeyi unutma. diff --git a/api/src/Sozsoft.Platform.DbMigrator/Seeds/LanguagesData.json b/api/src/Sozsoft.Platform.DbMigrator/Seeds/LanguagesData.json index d715836..f173874 100644 --- a/api/src/Sozsoft.Platform.DbMigrator/Seeds/LanguagesData.json +++ b/api/src/Sozsoft.Platform.DbMigrator/Seeds/LanguagesData.json @@ -13883,8 +13883,8 @@ { "resourceName": "Platform", "key": "App.Listform.ListformField.IP", - "en": "IP", - "tr": "Ip Adresi" + "en": "IP Address", + "tr": "IP Adresi" }, { "resourceName": "Platform", diff --git a/claude.md b/claude.md new file mode 100644 index 0000000..5d8016e --- /dev/null +++ b/claude.md @@ -0,0 +1,71 @@ +# 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