claude instructions düzenlemesi
This commit is contained in:
parent
9981d5b19a
commit
ae7ddf6c7f
4 changed files with 3076 additions and 240 deletions
65
.github/instructions/ai.instructions.md
vendored
65
.github/instructions/ai.instructions.md
vendored
|
|
@ -19,6 +19,7 @@ Companion documents (this file wins on conflict):
|
||||||
| Document | Scope |
|
| Document | Scope |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| `lowcode.instructions.md` | **Authoring reference**: exact schemas, enum values and worked examples for producing wizard screens, editor scripts, custom components, SQL objects and endpoints. Read it before writing any artifact. |
|
| `lowcode.instructions.md` | **Authoring reference**: exact schemas, enum values and worked examples for producing wizard screens, editor scripts, custom components, SQL objects and endpoints. Read it before writing any artifact. |
|
||||||
|
| `lowcode-reference.instructions.md` | **Capability inventory**: field-by-field contract of every ListForm/ListFormField JSON column, chart and pivot options, SQL command hooks, Visual Designer toolbox, the scheduled-mail module and (§12) every ready-made screen under the Saas and Administration menus. Sweep its §0 checklist before producing a screen or component; a request whose answer already exists as a platform screen (§12.5) is configured there, not rebuilt. |
|
||||||
| `dotnet.instructions.md` | Binding code standard for everything under `api/` |
|
| `dotnet.instructions.md` | Binding code standard for everything under `api/` |
|
||||||
| `list.instructions.md` | Step-by-step procedure for adding a module / list through seeders |
|
| `list.instructions.md` | Step-by-step procedure for adding a module / list through seeders |
|
||||||
| `../../README.md` | Technical map: what exists, where it lives, how it is wired |
|
| `../../README.md` | Technical map: what exists, where it lives, how it is wired |
|
||||||
|
|
@ -51,11 +52,25 @@ System nature:
|
||||||
3. Every proposal must include tenant and permission design.
|
3. Every proposal must include tenant and permission design.
|
||||||
4. Never bypass platform authorization patterns.
|
4. Never bypass platform authorization patterns.
|
||||||
5. Never hardcode secrets, tenant ids, or connection strings.
|
5. Never hardcode secrets, tenant ids, or connection strings.
|
||||||
|
6. **Stay inside the framework; ask before stepping out.** The platform may extend itself through
|
||||||
|
its own mechanisms (seed artifacts; adding a missing event, prop, or small backward-compatible
|
||||||
|
capability to an existing UI component — when Developer Kit tooling builds ~70% of the
|
||||||
|
requested component, the rest is completed with such small additions, never with a new
|
||||||
|
component; backward-compatible additions to script recipes / editor options / tokens).
|
||||||
|
Anything beyond that — a new React component or page, a new toolbox family, core engine changes (ListForm
|
||||||
|
runtime, seeders, code generator, auth, DataSourceManager, dispatcher/compiler), new ABP
|
||||||
|
entity/module/migration, platform table schema changes, new NuGet/npm dependencies, `Routes`
|
||||||
|
in `MenusData.json`, new external integrations — is **out of frame**: finish everything that
|
||||||
|
fits inside the frame first, then ask the user with a single question (why configuration is
|
||||||
|
insufficient, the smallest change that works, files touched, rollback) and proceed **only with
|
||||||
|
explicit approval**. Approval is per request and does not carry over. Full lists:
|
||||||
|
`lowcode.instructions.md` §0.8.
|
||||||
|
|
||||||
Exception policy:
|
Exception policy:
|
||||||
|
|
||||||
- Code-level React or backend development can be considered only if user explicitly requests code implementation and configuration path is insufficient.
|
- 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.
|
- If exception is required, AI must explain why configuration-based options are not enough.
|
||||||
|
- Never say "cannot be done": the answer is either an in-frame build or an approval question.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -293,6 +308,13 @@ canonical shape drops the dialog to raw SQL mode, so hand-editing a designed vie
|
||||||
designer. Aggregations available in the Group By column: `GroupBy`, `Where`, `SUM`, `COUNT`,
|
designer. Aggregations available in the Group By column: `GroupBy`, `Where`, `SUM`, `COUNT`,
|
||||||
`COUNT_DISTINCT`, `AVG`, `MIN`, `MAX`.
|
`COUNT_DISTINCT`, `AVG`, `MIN`, `MAX`.
|
||||||
|
|
||||||
|
Persistence: only the **table designer's** deploy writes a seed file automatically
|
||||||
|
(`{sql|postgres}/object/{TableName}.sql`, full CREATE script, via `save-table-script`). View
|
||||||
|
Designer deploys and any DDL run from the SQL editor (views, procedures, functions) reach the
|
||||||
|
database only — their seed files under `{sql|postgres}/object/` must be written explicitly.
|
||||||
|
Full mechanics and the SP/function production patterns: `lowcode.instructions.md` §8.1–§8.2.1
|
||||||
|
and §9.5.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 11. Integrations
|
## 11. Integrations
|
||||||
|
|
@ -423,7 +445,8 @@ When configuration cannot satisfy requirement:
|
||||||
1. Try SQL-based design
|
1. Try SQL-based design
|
||||||
2. Try Custom Endpoint
|
2. Try Custom Endpoint
|
||||||
3. Try Dynamic Service
|
3. Try Dynamic Service
|
||||||
4. Propose minimal code change with explicit justification
|
4. Propose minimal code change with explicit justification — this step is out of frame:
|
||||||
|
**ask and wait for approval before touching code** (rule 3.6).
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -759,26 +782,38 @@ When user asks for a screen/module, AI must answer in this order:
|
||||||
|
|
||||||
AI should produce practical, copy-adaptable artifact definitions and avoid abstract-only explanations.
|
AI should produce practical, copy-adaptable artifact definitions and avoid abstract-only explanations.
|
||||||
|
|
||||||
### 31.9 Screen brief and image-based requests
|
### 31.9 Screen brief, discovery questions and image-based requests
|
||||||
|
|
||||||
A request arrives either as prose or as a **screenshot / mockup / photo** of the desired screen.
|
A request arrives either as prose or as a **screenshot / mockup / photo** of the desired screen.
|
||||||
Both enter the same pipeline:
|
Both enter the same pipeline — and for a **new screen/component the pipeline starts with
|
||||||
|
questions, not files**:
|
||||||
|
|
||||||
1. Turn it into a single screen brief — purpose, data source, columns and editors, layouts,
|
1. **Run the discovery round** (`lowcode.instructions.md` §0.6). Ask in batches (max 4 questions
|
||||||
actions, sub-screens, widgets, approval flow, menu, permissions, tenancy, language texts.
|
per round, each with 2–4 options and a recommended default), max three rounds. Round 1 always
|
||||||
For an image, read it first: page regions → main region type → toolbar → columns → filters →
|
covers: screen kind (List/Wizard vs Custom Component vs single-record form), data source,
|
||||||
form controls → row actions.
|
owning module, and tenancy scope. Round 2 uses the path-specific question set (§0.6.3 for
|
||||||
2. Pick the tool: grid-shaped work → SQL Query Manager + Wizard; free layout / dashboard /
|
List, §0.6.4 for Custom). Never ask what the repo already answers — search first, confirm
|
||||||
single-record custom form → Custom Component. **When in doubt, pick the Wizard.**
|
findings instead of re-asking. If the user says "you decide / don't ask", skip the round and
|
||||||
3. Produce the seed files in dependency order.
|
build on defaults.
|
||||||
|
2. Turn the answers into a single screen brief — purpose, data source, columns and editors,
|
||||||
|
layouts, actions, sub-screens, widgets, approval flow, menu, permissions, tenancy, language
|
||||||
|
texts. For an image, read it first (page regions → main region type → toolbar → columns →
|
||||||
|
filters → form controls → row actions); the image answers most of round 2, so ask only what
|
||||||
|
an image cannot show (§0.7.4).
|
||||||
|
3. **Get the brief confirmed before writing any seed file.** Mark defaulted lines `(varsayılan)`
|
||||||
|
so the user sees what they are approving.
|
||||||
|
4. Pick the tool: grid-shaped work → SQL Query Manager + Wizard; free layout / dashboard /
|
||||||
|
single-record custom form → Custom Component. **When in doubt, recommend the Wizard.**
|
||||||
|
5. Produce the seed files in dependency order, then list them and restate the defaulted choices.
|
||||||
|
|
||||||
An image is a reference, not a pixel contract: build the closest thing the platform's own
|
An image is a reference, not a pixel contract: build the closest thing the platform's own
|
||||||
components give, and state at the end what had no equivalent. Never block on missing detail —
|
components give, and state at the end what had no equivalent. Three things are never assumed,
|
||||||
state the assumption and continue; ask only where a wrong guess loses data or picks the wrong
|
always asked: which table is written to, who approves (when there is an approval flow), and the
|
||||||
approver.
|
formula of any calculation/business rule. This question-first rule applies only to producing a
|
||||||
|
**new** screen/component; fixes, field additions, debugging and explanations proceed directly.
|
||||||
|
|
||||||
The concrete brief template, the image-element → artifact mapping and the visual-control →
|
The concrete question sets, brief template, the image-element → artifact mapping and the
|
||||||
`EditorType` mapping are in `lowcode.instructions.md` §0.6–§0.7.
|
visual-control → `EditorType` mapping are in `lowcode.instructions.md` §0.6–§0.7.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
1373
.github/instructions/lowcode-reference.instructions.md
vendored
Normal file
1373
.github/instructions/lowcode-reference.instructions.md
vendored
Normal file
File diff suppressed because it is too large
Load diff
1854
.github/instructions/lowcode.instructions.md
vendored
1854
.github/instructions/lowcode.instructions.md
vendored
File diff suppressed because it is too large
Load diff
24
claude.md
24
claude.md
|
|
@ -48,6 +48,7 @@ options you rejected.
|
||||||
3. Every implementation proposal must include tenant and permission design.
|
3. Every implementation proposal must include tenant and permission design.
|
||||||
4. Never bypass platform authorization patterns.
|
4. Never bypass platform authorization patterns.
|
||||||
5. Never hardcode secrets, tenant IDs, or connection strings.
|
5. Never hardcode secrets, tenant IDs, or connection strings.
|
||||||
|
6. Never step outside the framework without explicit approval (standing default 10).
|
||||||
|
|
||||||
Exception:
|
Exception:
|
||||||
|
|
||||||
|
|
@ -106,6 +107,7 @@ These sections encode expectations the user will **not** repeat in every prompt.
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| Platform davranışı, karar sırası, çıktı sözleşmesi | `.github/instructions/ai.instructions.md` |
|
| Platform davranışı, karar sırası, çıktı sözleşmesi | `.github/instructions/ai.instructions.md` |
|
||||||
| **Artefakt üretimi**: seed şemaları, enum değerleri, çalışan örnekler | `.github/instructions/lowcode.instructions.md` |
|
| **Artefakt üretimi**: seed şemaları, enum değerleri, çalışan örnekler | `.github/instructions/lowcode.instructions.md` |
|
||||||
|
| **Yetenek envanteri**: JSON kolonlarının alan alan sözleşmesi, grafik/pivot/tasarımcı/mail modülü, Saas + Administration menüsündeki hazır ekranlar | `.github/instructions/lowcode-reference.instructions.md` |
|
||||||
| `api/` kod standardı (sürüm, nullable, ölü kod, modern C#, ABP katmanları) | `.github/instructions/dotnet.instructions.md` |
|
| `api/` kod standardı (sürüm, nullable, ölü kod, modern C#, ABP katmanları) | `.github/instructions/dotnet.instructions.md` |
|
||||||
| Modül/liste ekleme prosedürü, seeder dosya sorumlulukları | `.github/instructions/list.instructions.md` |
|
| Modül/liste ekleme prosedürü, seeder dosya sorumlulukları | `.github/instructions/list.instructions.md` |
|
||||||
| Ne nerede yaşıyor, hangi ekran ne yapıyor | `README.md` |
|
| Ne nerede yaşıyor, hangi ekran ne yapıyor | `README.md` |
|
||||||
|
|
@ -127,15 +129,27 @@ Bir çelişki varsa sıra: `ai.instructions.md` → `dotnet.instructions.md` →
|
||||||
metin önerme.
|
metin önerme.
|
||||||
5. **Runtime'da üretilen her artefakt** (wizard, custom component, crud endpoint) → ilgili seed
|
5. **Runtime'da üretilen her artefakt** (wizard, custom component, crud endpoint) → ilgili seed
|
||||||
dosyası da yazılır/güncellenir. Veritabanı sıfırlandığında geri gelmeyen bir şey üretme.
|
dosyası da yazılır/güncellenir. Veritabanı sıfırlandığında geri gelmeyen bir şey üretme.
|
||||||
6. **Ekran/komponent talebi — yazılı ya da görsel** → önce ekran tarifi çıkar, sonra yolu seç
|
6. **Yeni ekran/komponent talebi — yazılı ya da görsel** → dosya yazmadan önce **keşif turu**:
|
||||||
(grid benzeri iş → SQL Query Manager + Wizard; serbest yerleşim → Custom Component),
|
toplu sorularla (tur başına en fazla 4, seçenekli, önerilen varsayılanlı) ekran türü, veri
|
||||||
sonra `configs/seeds/` altına dosyaları üret. Şüphede Wizard. Ekran görüntüsü piksel
|
kaynağı, modül, kapsam ve yolun soru setini al; tarifi kur ve **onaylat**, sonra
|
||||||
sözleşmesi değildir; platformun kendi bileşenleriyle en yakın karşılık üretilir.
|
`configs/seeds/` altına üret. Şüphede Wizard. Kullanıcı "sorma / sen seç" derse
|
||||||
Ayrıntı: `lowcode.instructions.md` §0.
|
varsayılanlarla üret ve sonunda listele. Depodan okunabilen şeyi sorma; tabloya yazma hedefi,
|
||||||
|
onaycı ve hesap formülü asla varsayılmaz. Ekran görüntüsü piksel sözleşmesi değildir;
|
||||||
|
görsel Tur 2'nin çoğunu cevaplar, yalnızca görselden okunamayanlar sorulur.
|
||||||
|
Bu kural yalnızca **yeni üretim** içindir; düzeltme/alan ekleme/debug doğrudan yapılır.
|
||||||
|
Ayrıntı: `lowcode.instructions.md` §0.6–§0.7.
|
||||||
7. **Ekran içi hesap/koşul ihtiyacı** → önce `EditorScript` (Script Builder tarifleri), sonra
|
7. **Ekran içi hesap/koşul ihtiyacı** → önce `EditorScript` (Script Builder tarifleri), sonra
|
||||||
`EditorOptions`; kod yazmak son çare.
|
`EditorOptions`; kod yazmak son çare.
|
||||||
8. **SQL** → her zaman parametreli. String birleştirme ile sorgu kurma.
|
8. **SQL** → her zaman parametreli. String birleştirme ile sorgu kurma.
|
||||||
9. **Silme** → `DeleteCommand = DefaultDeleteCommand("{Tablo}")`; ham SQL string'i yazma.
|
9. **Silme** → `DeleteCommand = DefaultDeleteCommand("{Tablo}")`; ham SQL string'i yazma.
|
||||||
|
10. **Çerçeve sınırı** → uygulama kendini kendi mekanizmalarıyla geliştirir (seed artefaktları;
|
||||||
|
var olan `ui` bileşenine eksik olay/prop/küçük yetenek ekleme — komponentin %70'i hazır
|
||||||
|
araçlarla kuruluyorsa kalanı bu eklemelerle tamamlanır, yeni bileşen yazılmaz; geriye dönük
|
||||||
|
uyumlu tarif/seçenek/token ekleme).
|
||||||
|
Bunun dışına çıkan her şey — yeni React bileşeni/sayfası, çekirdek motor, yeni entity/
|
||||||
|
migration, platform tablosu şeması, yeni paket, `Routes`, dış entegrasyon — **önce sorulur,
|
||||||
|
yalnızca onayla yapılır**; onay talebe özeldir. Çerçeve içinde yapılabilen kısım sorudan önce
|
||||||
|
bitirilir. "Yapılamaz" cevabı yoktur. Listeler: `lowcode.instructions.md` §0.8.
|
||||||
|
|
||||||
### Cross-cutting: touching one thing means touching these too
|
### Cross-cutting: touching one thing means touching these too
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue