claude instructions düzenlemesi

.github/instructions/ai.instructions.md

@@ -19,6 +19,7 @@ Companion documents (this file wins on conflict):
 | 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-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/` |
 | `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 |
@@ -51,11 +52,25 @@ System nature:
 3. Every proposal must include tenant and permission design.
 4. Never bypass platform authorization patterns.
 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:
 
 - 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.
+- 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`,
 `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
@@ -423,7 +445,8 @@ 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
+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.
 
-### 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.
-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,
-   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.
-2. Pick the tool: grid-shaped work → SQL Query Manager + Wizard; free layout / dashboard /
-   single-record custom form → Custom Component. **When in doubt, pick the Wizard.**
-3. Produce the seed files in dependency order.
+1. **Run the discovery round** (`lowcode.instructions.md` §0.6). Ask in batches (max 4 questions
+   per round, each with 2–4 options and a recommended default), max three rounds. Round 1 always
+   covers: screen kind (List/Wizard vs Custom Component vs single-record form), data source,
+   owning module, and tenancy scope. Round 2 uses the path-specific question set (§0.6.3 for
+   List, §0.6.4 for Custom). Never ask what the repo already answers — search first, confirm
+   findings instead of re-asking. If the user says "you decide / don't ask", skip the round and
+   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
-components give, and state at the end what had no equivalent. Never block on missing detail —
-state the assumption and continue; ask only where a wrong guess loses data or picks the wrong
-approver.
+components give, and state at the end what had no equivalent. Three things are never assumed,
+always asked: which table is written to, who approves (when there is an approval flow), and the
+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 →
-`EditorType` mapping are in `lowcode.instructions.md` §0.6–§0.7.
+The concrete question sets, brief template, the image-element → artifact mapping and the
+visual-control → `EditorType` mapping are in `lowcode.instructions.md` §0.6–§0.7.
 
 ---
 

claude.md

@@ -48,6 +48,7 @@ options you rejected.
 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.
+6. Never step outside the framework without explicit approval (standing default 10).
 
 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` |
 | **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` |
 | 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` |
@@ -127,15 +129,27 @@ Bir çelişki varsa sıra: `ai.instructions.md` → `dotnet.instructions.md` →
    metin önerme.
 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.
-6. **Ekran/komponent talebi — yazılı ya da görsel** → önce ekran tarifi çıkar, sonra yolu seç
-   (grid benzeri iş → SQL Query Manager + Wizard; serbest yerleşim → Custom Component),
-   sonra `configs/seeds/` altına dosyaları üret. Şüphede Wizard. Ekran görüntüsü piksel
-   sözleşmesi değildir; platformun kendi bileşenleriyle en yakın karşılık üretilir.
-   Ayrıntı: `lowcode.instructions.md` §0.
+6. **Yeni ekran/komponent talebi — yazılı ya da görsel** → dosya yazmadan önce **keşif turu**:
+   toplu sorularla (tur başına en fazla 4, seçenekli, önerilen varsayılanlı) ekran türü, veri
+   kaynağı, modül, kapsam ve yolun soru setini al; tarifi kur ve **onaylat**, sonra
+   `configs/seeds/` altına üret. Şüphede Wizard. Kullanıcı "sorma / sen seç" derse
+   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
    `EditorOptions`; kod yazmak son çare.
 8. **SQL** → her zaman parametreli. String birleştirme ile sorgu kurma.
 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