AI Instructions
This commit is contained in:
Sedat ÖZTÜRK
parent
cf6ded1105
commit
3baa7def61
4 changed files with 933 additions and 2 deletions
711
.github/instructions/ai.instructions.md
vendored
Normal file
711
.github/instructions/ai.instructions.md
vendored
Normal file
|
|
@ -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.
|
||||||
149
.github/instructions/list.instructions.md
vendored
Normal file
149
.github/instructions/list.instructions.md
vendored
Normal file
|
|
@ -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.
|
||||||
|
|
@ -13883,8 +13883,8 @@
|
||||||
{
|
{
|
||||||
"resourceName": "Platform",
|
"resourceName": "Platform",
|
||||||
"key": "App.Listform.ListformField.IP",
|
"key": "App.Listform.ListformField.IP",
|
||||||
"en": "IP",
|
"en": "IP Address",
|
||||||
"tr": "Ip Adresi"
|
"tr": "IP Adresi"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"resourceName": "Platform",
|
"resourceName": "Platform",
|
||||||
|
|
|
||||||
71
claude.md
Normal file
71
claude.md
Normal file
|
|
@ -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
|
||||||
Loading…
Reference in a new issue