tillerhand 3.43.0 → 3.47.0

package/.claude/commands/adopt.md

@@ -1,103 +1,104 @@
 ---
-description: Var olan (ilerlemiş, beğenilmeyen veya iyileştirilecek) bir projeyi kite alır. Kodu tarar, belgeleri koddan çıkarır, soru sorarak doğrular, testleri ve yapıyı kitin düzenine getiren bir uyum yol haritası çıkarır.
-argument-hint: [boş | projeyle ilgili kısa not]
+description: Brings an existing project (in progress, disliked or needing improvement) into the kit. Scans the code, derives the docs from the code, verifies by asking questions, and produces an alignment roadmap that brings tests and structure to the kit's layout.
+argument-hint: [empty | short note about the project]
 ---
 
-Not: $ARGUMENTS
+Note: $ARGUMENTS
 
-Bu bir **9 adımlı uyum sihirbazı** (0-9). `/start`'ın var olan kod için olan karşılığıdır. Fikirden değil koddan başlar, ama kararları yine kullanıcı verir: Her kararı `docs/workflow/decision-protocol.md`'ye göre sor ve verildiği anda `docs/decisions/log.md`'ye yaz. Bu oturumda uygulama kodunu değiştirme ve dosya taşıma. Taşıma ve düzeltmeler yol haritasındaki görevlerle, `/build` ile yapılır.
+This is a **9-step alignment wizard** (0-9). It is the counterpart of `/start` for existing code. It starts from the code, not from an idea, but the user still makes the decisions: Ask every decision per `docs/workflow/decision-protocol.md` and write it to `docs/decisions/log.md` the moment it is made. Do not change application code or move files in this session. Moves and fixes are done with the roadmap tasks, through `/build`.
 
-**Önkoşul:** Kit bu klasöre `init` ile kurulmuş olmalı (`.kit.json` var, `type` boş). Kurulmamışsa kullanıcıya kurulum komutunu ver: `node <kit klasörü>/kit/kit.mjs init`. Kurulumdan sonra yeni oturum açılması gerekir.
+**Prerequisite:** The kit must be installed in this folder with `init` (`.kit.json` exists, `type` empty). If not installed, give the user the install command: `node <kit folder>/kit/kit.mjs init`. A new session must be opened after installation.
 
-**Devam etme:** `docs/workflow/progress.md` → `**Aktif faz:** Başlangıç (uyum)` ve `**Başlangıç adımı:**` 0'dan büyükse kaldığın adımdan devam et. Her adım bitince bu satırı (`N/9`) ve `**Son güncelleme:**` satırını güncelle, sonra durum bloğunu yaz.
+**Resuming:** If `docs/workflow/progress.md` → `**Aktif faz:** Başlangıç (uyum)` and `**Başlangıç adımı:**` is greater than 0, resume from that step. When a step ends, update this line (`N/9`) and the `**Son güncelleme:**` line, then write the status block.
 
-**Mevcut koda saygı:** Kurulum projenin dosyalarının üzerine yazmaz; kitin hali yanına `<dosya>.kit-new` olarak konur. Bunları Adım 2'de tek tek ele al.
+**Respect existing code:** Installation does not overwrite the project's files; the kit's version is placed next to it as `<file>.kit-new`. Handle them one by one in Step 2.
 
 ---
 
-## Adım 0: Hazırlık
+## Step 0: Preparation
 
+0. **Language (before anything else):** Apply the language question at the start of `/start` Step 0 exactly (question in English, Turkish / English / Other, `node .claude/hooks/lang.mjs --set <code>`, translation if needed). If a language is already chosen, do not ask again.
 1. `docs/workflow/progress.md` → `**Aktif faz:** Başlangıç (uyum)`, `**Başlangıç adımı:** 0/9`.
-2. `/start` Adım 0'daki şu maddeleri aynen uygula: Profil (0), anlatıcı mod (0b), araç (0c), auto memory (0d), model ve effort (0e, `docs/workflow/models.md`), ortam kontrolü (1), eklentiler (2), caveman (3), kod haritası (5), bildirimler (6), pano (6b). Var olan projede kod haritası daha da faydalıdır; önerilen seçenek "Kur" olsun.
-3. **Tarama derinliği:** Limiti oku ve sor. Tahmini maliyetleri göster:
-   - **Hızlı tarama (Önerilen, Pro'da):** Yapı, stack, testler, git geçmişi, belgeler. 5 saatlik limitin yaklaşık %10-20'si.
-   - **Derin tarama:** Hızlı taramaya ek olarak seçilen bulgu raporları (`/findings-tech`, `-security`, `-ux` vb.). Rapor başına yaklaşık %8-15 daha. Hangi raporların çalışacağını çoklu seçimle sor.
-   Seçimi `**Profil:**` satırına ekle (örn. `Hafif · tarama: Hızlı`).
+2. Apply these items from `/start` Step 0 exactly: Profile (0), narrator mode (0b), tool (0c), auto memory (0d), model and effort (0e, `docs/workflow/models.md`), environment check (1), plugins (2), caveman (3), code map (5), notifications (6), dashboard (6b). The code map is even more useful in an existing project; make "Install" the recommended option.
+3. **Scan depth:** Read the limit and ask. Show the estimated costs:
+   - **Quick scan (Recommended, on Pro):** Structure, stack, tests, git history, docs. About 10-20% of the 5-hour limit.
+   - **Deep scan:** In addition to the quick scan, the selected findings reports (`/findings-tech`, `-security`, `-ux` etc.). About 8-15% more per report. Ask which reports to run with multi-select.
+   Append the choice to the `**Profil:**` line (e.g. `Hafif · scan: Hızlı`).
 
-## Adım 1: Tara (salt okunur)
+## Step 1: Scan (read-only)
 
-Dosyaları toptan okuma: kod haritası bağlıysa önce onu kullan, yoksa paket dosyalarından, klasör ağacından ve giriş noktalarından başla. Çıkar:
-1. **Stack:** Dil, framework, veritabanı, auth, hosting, paket yöneticisi. Kilit dosyası var mı? Çalışma ortamı sürümü sabit mi (`.nvmrc`, `.python-version`, `engines`)?
-2. **Yapı:** Klasör ağacı (2-3 seviye), giriş noktaları, katmanlar. Kitin özellik bazlı yapısından (`features/<özellik>/`) ne kadar uzak?
-3. **Özellikler:** Rotalar, ekranlar, API uçları ve modellerden kullanıcıya görünen özellik listesi.
-4. **Testler:** Test altyapısı var mı? Testleri çalıştır, sonucu göster: kaç test, kaçı kırmızı, kapsanan alanlar. Doğrulama satırı olmayan ya da her şeyi taklitle (mock) geçen testleri ayrıca işaretle.
-5. **Kurulabilirlik:** README'de kurulum adımı, `.env.example`, sistem bağımlılıkları.
-6. **Git geçmişi:** Son 30 commit'in özeti, aktif dallar, en çok değişen dosyalar (riskli bölgeler).
-7. **Mevcut belgeler:** README, eski `CLAUDE.md` ve `AGENTS.md` (yerinde duruyorlar; kitinkiler `.kit-new` uzantılı), varsa docs klasörü.
-8. **Kaynağı olmayan parçalar:** Repoya girmiş derlenmiş paket, küçültülmüş JS, Electron ASAR veya kaynağı kayıp bağımlılık. Varsa listele. İçini anlamak gerekirse rea CLI öner (`docs/workflow/mcp-catalog.md` → rea): sadece projenin sahibi olduğu veya incelemeye yetkili olduğu parçalar için, lisansını kontrol ederek.
+Do not read files in bulk: if the code map is connected, use it first; otherwise start from the package files, the folder tree and the entry points. Extract:
+1. **Stack:** Language, framework, database, auth, hosting, package manager. Is there a lock file? Is the runtime version pinned (`.nvmrc`, `.python-version`, `engines`)?
+2. **Structure:** Folder tree (2-3 levels), entry points, layers. How far is it from the kit's feature-based structure (`features/<feature>/`)?
+3. **Features:** The user-visible feature list from routes, screens, API endpoints and models.
+4. **Tests:** Is there a test setup? Run the tests and show the result: how many tests, how many red, which areas are covered. Also flag tests that have no verification line or that pass everything with mocks.
+5. **Installability:** Setup steps in the README, `.env.example`, system dependencies.
+6. **Git history:** Summary of the last 30 commits, active branches, most changed files (risky zones).
+7. **Existing docs:** README, the old `CLAUDE.md` and `AGENTS.md` (they stay in place; the kit's versions have the `.kit-new` extension), the docs folder if any.
+8. **Parts without source:** A compiled package, minified JS, an Electron ASAR or a dependency with lost source that entered the repo. List them if present. If their inside needs to be understood, suggest the rea CLI (`docs/workflow/mcp-catalog.md` → rea): only for parts the project owner owns or is authorized to inspect, checking the license.
 
-Bulguları kısa bir tablo halinde göster. Hızlı taramada kodun içine dalma: sadece yapı ve özet.
+Show the findings as a short table. In a quick scan do not dive into the code: only structure and summary.
 
-## Adım 2: Tip ve kurulum
+## Step 2: Type and installation
 
-1. Taramaya göre tipi öner ve onaylat (web-saas / mobile / backend; AI özelliği var mı; Türkiye'de satış veya Türk kullanıcı varsa Türkiye eki `tr`, ayrıntı `/start` Adım 2).
-2. Kur: `node <kit klasörü>/kit/kit.mjs install --type <tip> [--addons ai,tr] --project .` (kit klasörü `.kit.json` → `kit` alanında; alan `local` ise klasör git dışı `.kit.local.json` → `kit`'te, o dosya yoksa proje başka makinede açılmıştır: kullanıcıya kit klasörünü sor ya da `npx -y tillerhand@<.kit.json → version>` kullan; alan `npx:tillerhand@<sürüm>` ise `npx -y tillerhand@<sürüm> install ...`; sürüm tam olarak `1.2.3` biçiminde ve `.kit.json` → `version` ile aynı değilse dur ve sor). Araç `init`'te seçilmediyse Adım 0'daki seçimi `--tool <liste>` olarak ekle.
-3. **`.kit-new` dosyaları:** Her biri için (`CLAUDE.md` ve `AGENTS.md` hariç, onlar Adım 4'te) farkı özetle ve karar olarak sor: kitinkini al / projeninkini koru / birleştir. Örnekler: `.env.example` genelde birleştirilir; `ci.yml` için mevcut CI'ın yaptıklarını kitinkiyle karşılaştır. Sonra `.kit-new` dosyasını sil.
+1. Propose the type based on the scan and get it approved (web-saas / mobile / backend; is there an AI feature; if there are sales in Turkey or Turkish users, the Turkey add-on `tr`, details in `/start` Step 2).
+2. Install: `node <kit folder>/kit/kit.mjs install --type <type> [--addons ai,tr] --project .` (the kit folder is in the `.kit.json` → `kit` field; if the field is `local`, the folder is in the git-ignored `.kit.local.json` → `kit`, and if that file is missing, the project was opened on another machine: ask the user for the kit folder or use `npx -y tillerhand@<.kit.json → version>`; if the field is `npx:tillerhand@<version>`, `npx -y tillerhand@<version> install ...`; if the version is not exactly in the form `1.2.3` and the same as `.kit.json` → `version`, stop and ask). If the tool was not chosen at `init`, add the choice from Step 0 as `--tool <list>`.
+3. **`.kit-new` files:** For each one (except `CLAUDE.md` and `AGENTS.md`, which are in Step 4), summarize the difference and ask as a decision: take the kit's / keep the project's / merge. Examples: `.env.example` is usually merged; for `ci.yml`, compare what the existing CI does with the kit's. Then delete the `.kit-new` file.
 
-## Adım 3: Belgeleri koddan çıkar
+## Step 3: Derive the docs from the code
 
-Kodun söylediğini taslak olarak yaz, koddan anlaşılmayanı sor (AskUserQuestion, turlar halinde):
-1. **`docs/product/prd.md`:** Problem, hedef kullanıcı, mevcut özellikler (koddan), kabul kriterleri taslağı. Sor: Projenin amacı ve kitlesi doğru anlaşıldı mı? **Neyi beğenmiyorsun, neyi iyileştirmek istiyorsun?** (çoklu seçim + serbest). Eksik veya yarım kalan özellikler hangileri?
-2. **`docs/architecture/stack.md`:** "Seçilen teknolojiler" tablosunu mevcut stack'le doldur. Kitin kataloğundan farklı seçimler hata değildir; değiştirmeyi önermek ayrı bir karardır ve sadece ciddi bir sebep varsa sorulur (güvenlik, bakımı bitmiş sürüm, maliyet).
-3. **`docs/architecture/overview.md`, `docs/product/glossary.md`:** Veri modeli, servisler, ana kavramlar.
-3b. **Araştırma (pahalı adım, isteğe bağlı):** Benzer projeler ve rakiplerle karşılaştırma için `/research` öner (hızlı: limitin yaklaşık %10-15'i). Yap / Sonraya bırak. Seçilen özellikler Adım 8'de Faz 3'e girer.
-4. **README:** Gereksinimler ve Kurulum bölümleri (`/start` Adım 4 madde 3a). Eksik kilit dosyası veya sürüm dosyası Adım 8'de ilk görevlerden biri olur.
+Write what the code says as a draft, ask what cannot be understood from the code (AskUserQuestion, in rounds):
+1. **`docs/product/prd.md`:** Problem, target user, current features (from the code), draft acceptance criteria. Ask: Were the project's purpose and audience understood correctly? **What do you dislike, what do you want to improve?** (multi-select + free text). Which features are missing or unfinished?
+2. **`docs/architecture/stack.md`:** Fill the "Seçilen teknolojiler" (chosen technologies) table with the current stack. Choices different from the kit's catalog are not errors; proposing a change is a separate decision and is asked only if there is a serious reason (security, an end-of-life version, cost).
+3. **`docs/architecture/overview.md`, `docs/product/glossary.md`:** Data model, services, main concepts.
+3b. **Research (expensive step, optional):** Suggest `/research` for comparison with similar projects and competitors (quick: about 10-15% of the limit). Do it / Leave for later. Selected features go into Phase 3 in Step 8.
+4. **README:** The "Requirements" and "Installation" sections (`/start` Step 4 item 3a). A missing lock file or version file becomes one of the first tasks in Step 8.
 
-## Adım 4: AGENTS.md ve CLAUDE.md'yi yeniden yaz
+## Step 4: Rewrite AGENTS.md and CLAUDE.md
 
-Ortak kurallar `AGENTS.md`'de (Claude Code, Codex, Antigravity okur); `CLAUDE.md` onu `@AGENTS.md` ile içe alır ve sadece Claude Code'a özel ekleri tutar.
+The shared rules are in `AGENTS.md` (read by Claude Code, Codex, Antigravity); `CLAUDE.md` imports it with `@AGENTS.md` and keeps only Claude Code-specific additions.
 
-1. Kitin `AGENTS.md` (veya `AGENTS.md.kit-new`) dosyasını temel al; proje adı, tek cümle tanım ve Komutlar bölümünü doldur. `CLAUDE.md` kitin `CLAUDE.md.kit-new` haline geçer. `init` projenin `AGENTS.md`'si yüzünden `CLAUDE.md`'ye `@AGENTS.md.kit-new` yazdıysa bu satırı `@AGENTS.md` yap.
-2. Eski `CLAUDE.md`'yi (ve varsa eski `AGENTS.md`'yi) oku ve içindeki projeye özel kuralları listele (kod stili, yasak komutlar, paket yöneticisi, ortam notları, dikkat edilecek yerler). Kitin kurallarıyla aynı olanları ayıkla.
-3. Kalanları **çoklu seçimle** sor: "Eski kurallardan hangileri yeni AGENTS.md'ye girsin?" Kitin kuralıyla çelişen varsa ayrıca belirt.
-4. Seçilenleri `AGENTS.md`'ye `## Proje kuralları` bölümü olarak ekle ("Temel kurallar"dan sonra; sadece Claude Code'a özel olanlar `CLAUDE.md`'ye). Eskileri `docs/archive/claude-md-eski.md` (ve `agents-md-eski.md`) olarak sakla, `.kit-new` dosyalarını sil.
+1. Take the kit's `AGENTS.md` (or `AGENTS.md.kit-new`) as the base; fill the project name, the one-sentence description and the "Komutlar" (commands) section. `CLAUDE.md` becomes the kit's `CLAUDE.md.kit-new` version. If `init` wrote `@AGENTS.md.kit-new` into `CLAUDE.md` because of the project's `AGENTS.md`, change this line to `@AGENTS.md`.
+2. Read the old `CLAUDE.md` (and the old `AGENTS.md` if any) and list the project-specific rules in them (code style, forbidden commands, package manager, environment notes, places to be careful). Filter out those that are the same as the kit's rules.
+3. Ask the rest with **multi-select**: "Which of the old rules should go into the new AGENTS.md?" If any conflicts with a kit rule, point it out separately.
+4. Add the selected ones to `AGENTS.md` as a `## Project rules` section (after "Core rules"; only the Claude Code-specific ones go to `CLAUDE.md`). Keep the old ones as `docs/archive/claude-md-eski.md` (and `agents-md-eski.md`), delete the `.kit-new` files.
 
-## Adım 5: Testler ve kritik akışlar
+## Step 5: Tests and critical flows
 
-1. Adım 1'deki test sonucunu hatırlat. Kırmızı testler ve hiçbir şeyi doğrulamayan testler bulgu olarak kaydedilir.
-2. Kritik akışları öner (giriş, ödeme, veri kaydı ve silme gibi; 3-7 akış) ve çoklu seçimle onaylat. `docs/quality/test-plan.md`'ye yaz.
-3. **Her kritik akışın doğru davranışını kullanıcıya sor** ("Şifre yanlışsa ne olmalı?" gibi somut sorular). Kodun şu anki davranışı test için kaynak değildir: kod yanlış olabilir. Kod ile cevap çelişirse bunu bulgu olarak yaz ve düzeltme görevini Adım 8'e ekle.
-4. Kural: Yapı taşınmadan önce bu akışlara uçtan uca test yazılır. Sonrasında her görev dokunduğu kodun testini kendisi yazar. Bütün projeye toplu test yazılmaz.
+1. Recall the test result from Step 1. Red tests and tests that verify nothing are recorded as findings.
+2. Propose the critical flows (such as sign-in, payment, data save and delete; 3-7 flows) and get them approved with multi-select. Write them to `docs/quality/test-plan.md`.
+3. **Ask the user the correct behavior of every critical flow** (concrete questions such as "What should happen if the password is wrong?"). The code's current behavior is not the source for tests: the code may be wrong. If the code and the answer conflict, write it as a finding and add the fix task to Step 8.
+4. Rule: Before the structure is moved, end-to-end tests are written for these flows. After that, each task writes the test of the code it touches. Tests are not written in bulk for the whole project.
 
-## Adım 6: Derin tarama (seçildiyse)
+## Step 6: Deep scan (if chosen)
 
-Adım 0'da seçilen bulgu raporlarını çalıştır (`/findings-all <türler>` veya tek tek). Kritik ve yüksek bulguları Adım 8'deki yol haritasına aday olarak al.
+Run the findings reports chosen in Step 0 (`/findings-all <types>` or one by one). Take the critical and high findings as candidates for the roadmap in Step 8.
 
-**İnsan için kod haritası (isteğe bağlı):** Kullanıcı kodu kendisi de görsel olarak keşfetmek isterse Understand-Anything öner (`yayin` paketi: `node .claude/hooks/tools.mjs --required yayin`). `/understand` ilk çalıştırmada bütün kodu okur, büyük projede pahalıdır: maliyeti söyle ve sor. Türkçe çıktı yok; `--language en` kullan. Sonra `/understand-dashboard`. Kod haritası (codebase-memory-mcp) ajan içindir, bu insan içindir; biri diğerinin yerine geçmez.
+**Code map for humans (optional):** If the user wants to explore the code visually themselves, suggest Understand-Anything (`yayin` package: `node .claude/hooks/tools.mjs --required yayin`). `/understand` reads all the code on the first run and is expensive in a big project: state the cost and ask. There is no Turkish output; use `--language en`. Then `/understand-dashboard`. The code map (codebase-memory-mcp) is for the agent, this one is for humans; neither replaces the other.
 
-## Adım 7: Kurul ve tasarım (isteğe bağlı)
+## Step 7: Board and design (optional)
 
-Pahalı adımlar: önce maliyeti söyle (`docs/workflow/usage-limits.md`), sonra sor: Yap / Hafif yap / Sonraya bırak.
-1. **Kurul:** `/start` Adım 6.
-2. **Tasarım** (arayüz varsa): Önce mevcut arayüzden `DESIGN.md` çıkar (`impeccable:impeccable` → extract); sonra sor: mevcut tasarımı koru / iyileştir / yeni yön (`/design genel`).
+Expensive steps: state the cost first (`docs/workflow/usage-limits.md`), then ask: Do it / Do it light / Leave for later.
+1. **Board:** `/start` Step 6.
+2. **Design** (if there is a UI): First extract `DESIGN.md` from the existing UI (`impeccable:impeccable` → extract); then ask: keep the current design / improve / new direction (`/design general`).
 
-## Adım 8: Uyum yol haritası → `docs/product/roadmap.md`
+## Step 8: Alignment roadmap → `docs/product/roadmap.md`
 
-Kitin "Faz 0" şablonunu bu projeye göre yeniden yaz. Sıra önemli:
-1. **Faz 0: Güvenli zemin.** Kilit dosyası ve sürüm dosyası, README kurulum adımları, CI ve pre-commit, kırmızı testlerin durumu. Sonra her kritik akış için ayrı görev: "Ö-xx uçtan uca testi (doğru davranışa göre)".
-2. **Faz 1: Yapıyı taşı.** Proje kitin klasör yapısına (`docs/architecture/structure.md`) taşınır. Her özellik ayrı görevdir (tek oturumluk). Kurallar:
-   - Taşıma ayrı bir dalda yapılır (`uyum/yapi`).
-   - Her görev sonunda testler ve uygulama çalışıyor olmalıdır. Testler yeşilse çalışan nokta kaydedilir (`checkpoint.mjs --save`). Bozulursa `/rollback` ile dönülür.
-   - Taşıma bitene kadar eski klasörler `.claude/structure.json` → `allow` listesine geçici olarak eklenir (CI yapı denetimi kırmızı kalmasın). Bu bir yapı kararıdır: kullanıcıya sor. Faz 1'in son görevi bu geçici satırları silmektir.
-3. **Faz 2: Bulgular.** Kullanıcının beğenmediği şeyler, kod ile doğru davranış arasındaki çelişkiler ve bulgu raporlarının kritik maddeleri, önem sırasıyla.
-4. **Faz 3 ve sonrası:** Yeni özellikler (PRD'deki eksikler).
+Rewrite the kit's "Faz 0" template (Phase 0) for this project. Order matters:
+1. **Phase 0: Safe ground.** Lock file and version file, README setup steps, CI and pre-commit, the state of the red tests. Then a separate task for each critical flow: "Ö-xx end-to-end test (by the correct behavior)".
+2. **Phase 1: Move the structure.** The project is moved to the kit's folder structure (`docs/architecture/structure.md`). Each feature is a separate task (single session). Rules:
+   - The move is done on a separate branch (`uyum/yapi`).
+   - At the end of each task the tests and the app must work. If the tests are green, the working point is saved (`checkpoint.mjs --save`). If it breaks, return with `/rollback`.
+   - Until the move ends, the old folders are temporarily added to the `.claude/structure.json` → `allow` list (so the CI structure check does not stay red). This is a structure decision: ask the user. The last task of Phase 1 is deleting these temporary lines.
+3. **Phase 2: Findings.** Things the user dislikes, conflicts between the code and the correct behavior, and the critical items of the findings reports, in order of importance.
+4. **Phase 3 and after:** New features (gaps in the PRD).
 
-Sor: "Faz 2'de önce hangisiyle başlayalım?" Yol haritasını özetle ve onay al.
+Ask: "Which one should we start with in Phase 2?" Summarize the roadmap and get approval.
 
-## Adım 9: Kapanış
+## Step 9: Closing
 
-1. `docs/workflow/progress.md`: Aktif faz `Faz 0`, aktif görev `G-001`, başlangıç adımı `9/9`, sıradaki adım, bekleyen kararlar.
-2. `node .claude/hooks/dashboard.mjs` çalıştır.
-3. Özet ver: tip ve stack, mevcut test durumu, kritik akışlar, AGENTS.md'ye taşınan kurallar, yapı farkı, en önemli 3 bulgu, ilk görev, kalan limit.
-4. Commit öner: `docs: kit uyumu (adopt)`.
-5. Son satır: "Devam: `/build G-001`".
+1. `docs/workflow/progress.md`: Active phase `Faz 0`, active task `G-001`, start step `9/9`, next step, pending decisions.
+2. Run `node .claude/hooks/dashboard.mjs`.
+3. Give a summary: type and stack, current test state, critical flows, rules moved to AGENTS.md, structure gap, the 3 most important findings, first task, remaining limit.
+4. Suggest a commit: `docs: kit uyumu (adopt)`.
+5. Last line: "Continue: `/build G-001`".

package/.claude/commands/ask-mode.md

@@ -1,15 +1,15 @@
 ---
-description: Soru modunu gösterir veya değiştirir (hangi konularda karar sorulacak).
-argument-hint: [boş | off <konu|hepsi> | on <konu|hepsi>]
+description: Shows or changes the question mode (on which topics decisions are asked).
+argument-hint: [empty | off <konu|hepsi> | on <konu|hepsi>]
 ---
 
-İstek: $ARGUMENTS
+Request: $ARGUMENTS
 
-Konular: `urun`, `teknik`, `tasarim`, `icerik`, `veri`, `guvenlik`, `maliyet` (`docs/workflow/decision-protocol.md` §1).
+Topics: `urun`, `teknik`, `tasarim`, `icerik`, `veri`, `guvenlik`, `maliyet` (`docs/workflow/decision-protocol.md` §1).
 
-- **Boşsa:** Mevcut soru modunu, kapalı konuları ve kapalıyken verilen otomatik kararları (`docs/decisions/log.md` → karar veren `otomatik`) göster.
-- **`off <konu|hepsi>`:** `docs/workflow/progress.md` → `**Soru modu:**` satırını güncelle. Örnek: `açık · kapalı konular: tasarim, icerik`. Hepsi kapalıysa: `kapalı · kapalı konular: hepsi`.
-- **`on <konu|hepsi>`:** Konuyu listeden çıkar. Liste boşalırsa: `açık · kapalı konular: yok`.
-- Konu adı listede yoksa en yakın konuyu öner ve sor.
+- **Empty:** Show the current question mode, the closed topics and the automatic decisions made while closed (`docs/decisions/log.md` → deciding party `otomatik`).
+- **`off <topic|hepsi>`:** Update the `**Soru modu:**` line in `docs/workflow/progress.md`. Example: `açık · kapalı konular: tasarim, icerik`. If all are closed: `kapalı · kapalı konular: hepsi`.
+- **`on <topic|hepsi>`:** Remove the topic from the list. If the list becomes empty: `açık · kapalı konular: yok`.
+- If the topic name is not in the list, propose the closest topic and ask.
 
-Değişikliği tek satırla onayla. Ayrıca hatırlat: Veri silme, prod deploy ve para harcatan işlemler soru modundan bağımsız olarak her zaman onay ister.
+Confirm the change in one line. Also remind: Deleting data, prod deploys and actions that spend money always ask for approval, regardless of question mode.

package/.claude/commands/board.md

@@ -1,23 +1,23 @@
 ---
-description: Uzman kurulunu kurar, değiştirir, toplar veya durumunu gösterir.
-argument-hint: [boş | setup | convene <plan|task|phase-end|release|konu> | council <soru>]
+description: Sets up, changes, convenes or shows the status of the expert board.
+argument-hint: [empty | setup | convene <plan|task|phase-end|release|konu> | council <soru>]
 ---
 
-İstek: $ARGUMENTS
+Request: $ARGUMENTS
 
-Önce `.claude/board/rules.md` ve `docs/workflow/board.md`'yi oku.
+First read `.claude/board/rules.md` and `docs/workflow/board.md`.
 
-- **Boş:** Kurulun durumunu göster: üyeler, inceleme rolünün modeli (`node .claude/hooks/models.mjs --show`), son 5 toplantı ve sonuçları, açık kritik bulgular, commit denetimi açık/kapalı. Kurul kurulmamışsa `/board setup` öner.
-- **`setup`:** rules.md §5'i uygula. Kurul zaten varsa, ne yapılacağını sor: üye ekle / üye çıkar / "Bu proje" bölümlerini güncel stack'e göre yenile. Model buradan değişmez: üyeler inceleme rolüyle çalışır (`docs/workflow/models.md`).
-- **`convene <tür>`:** rules.md §4'ü uygula.
-  - `plan`: son onaylanmamış plan
-  - `task`: aktif görevin değişiklikleri (`git diff`)
-  - `phase-end`: aktif fazın tüm değişiklikleri (faz başlangıcından bu yana `git log` ve diff özeti)
-  - `release`: tüm kod tabanı
-  - Diğer metinler: kullanıcının verdiği konu (örn. "ödeme akışı")
+- **Empty:** Show the board's status: members, the review role's model (`node .claude/hooks/models.mjs --show`), the last 5 meetings and their results, open critical findings, commit review on/off. If the board is not set up, propose `/board setup`.
+- **`setup`:** Apply rules.md §5. If the board already exists, ask what to do: add a member / remove a member / refresh the "This project" sections for the current stack. The model does not change here: members work with the review role (`docs/workflow/models.md`).
+- **`convene <type>`:** Apply rules.md §4.
+  - `plan`: the last unapproved plan
+  - `task`: the active task's changes (`git diff`)
+  - `phase-end`: all changes of the active phase (`git log` and diff summary since the phase start)
+  - `release`: the whole codebase
+  - Other texts: a topic given by the user (e.g. "payment flow")
 
-- **`council <soru>`:** Karar konseyi (`.claude/board/council.md`). Soruyu ve seçenekleri netleştir, eksikse önce kullanıcıya seçenekleri onaylat. Bitince başkanın önerisiyle kararı AskUserQuestion ile sor.
+- **`council <soru>`:** Decision council (`.claude/board/council.md`). Clarify the question and the options; if options are missing, first have the user confirm them. When done, ask for the decision with AskUserQuestion, using the chair's recommendation.
 
-Toplantıdan önce limiti kontrol et (`node .claude/hooks/usage.mjs`). Tam kurul toplantısı pahalıdır. Seviye sarı veya kırmızıysa tahmini maliyeti tek satırla söyle (`docs/workflow/usage-limits.md` §3). Tam kurul isteğe bağlı bir toplantıysa üye sayısını azaltmayı öner; limit yüzünden toplantıyı durdurma.
+Before a meeting, check the limit (`node .claude/hooks/usage.mjs`). A full board meeting is expensive. If the level is yellow or red, say the estimated cost in one line (`docs/workflow/usage-limits.md` §3). If the full board is an optional meeting, propose reducing the member count; do not stop the meeting because of the limit.
 
-Bitince: kurul sentezi, kullanıcıya sorulan kararlar, günlüğe eklenen satır, durum bloğu.
+When done: board synthesis, decisions asked of the user, the line added to the log, status block.

package/.claude/commands/build.md

@@ -1,51 +1,51 @@
 ---
-description: Yol haritasındaki sıradaki (veya verilen) görevi uygular, test eder, işaretler.
-argument-hint: [görev kodu, boşsa sıradaki görev]
+description: Implements the next (or given) roadmap task, tests it, marks it done.
+argument-hint: [task id, empty = next task]
 ---
 
-Görev: $ARGUMENTS
-Boşsa `docs/workflow/progress.md` → "Sıradaki adım" veya `docs/product/roadmap.md`'deki ilk işaretsiz görevi al.
+Task: $ARGUMENTS
+If empty, take `docs/workflow/progress.md` → "Sıradaki adım" (next step), or the first unchecked task in `docs/product/roadmap.md`.
 
-0. **Limit ve bağlam:** Limiti oku ve başlangıcı kaydet: `node .claude/hooks/progress.mjs --start` (masaüstünde durum çubuğu yok: `--limit <5 saatlik %>`, `get_usage`'dan). Bağlam %50'yi geçmişse önce `/wrap-up` + `/clear` öner. Seviye sarı/kırmızıysa veya tahmin kalan payı aşıyorsa bunu tek satırla söyle ve başla (`docs/workflow/usage-limits.md` §3; soru sorma). `docs/workflow/progress.md` → "Kaldığı yer" doluysa oradan devam et.
-0b. **Model ve effort** (`docs/workflow/models.md`): Son seçimi `node .claude/hooks/models.mjs --show` ile oku. Beş rol, rol başına tek soru (model ve effort birlikte, ör. "Sonnet · yüksek"; seçenekler models.md'de). İki AskUserQuestion çağrısı yap: önce plan, kod, test; sonra inceleme, doküman. Her soruda models.md'deki önerilen seçenek ilk sırada ve "(Önerilen)" etiketli; son seçim farklıysa o seçeneğin açıklamasına "son seçim" yaz. Test sorusunda önerilen, kod rolünün son seçiminden farklı modeldir (models.md). Cevabı `node .claude/hooks/models.mjs --set plan=<model>:<effort> code=… test=… review=… docs=…` ile kaydet; kod ve test aynı modelse betik uyarır, uyarıyı kullanıcıya ilet. Ana oturumun modeli veya effort'u plan rolünden farklıysa tek satırla `/model <ad>` ve `/effort <düzey>` öner. Soru modunda `maliyet` konusu kapalıysa sorma ve `--set` çalıştırma: son seçim geçerli kalır, durum bloğunda "otomatik" yaz.
-1. Görevi ve kabul kriterlerini bana tek cümleyle tekrar et. `docs/workflow/progress.md` → aktif görevi güncelle.
-2. Bu görev için onaylanmış bir plan yoksa ve 2'den fazla dosyaya dokunacaksa önce `/plan-task` adımlarını uygula (karar noktaları dahil), onay bekle.
-2a. **Akış:** `node .claude/hooks/flow.mjs --files <plandaki dosya sayısı>` (masaüstünde durum çubuğu yok: `--context` ve `--limit`'i `get_usage`'dan ver). Çıktı kodun ve doküman işinin nerede yapılacağını (ana oturum / alt ajan), görev sonu kurulunun kaç üyeyle ve paralel mi sırayla mı toplanacağını söyler (6b'de yeniden çalıştır: değişen yollardan üyeleri adıyla önerir); 2c, 6b ve 8 buna uyar. "Önce /clear öner" derse tek satırla öner.
-2b. **Önce testler, ayrı ajanla:** Testleri kodu yazan yazmaz (AGENTS.md kural 7). Akış ne derse desin `test-writer` alt ajanını test rolünün `model` ve `effort`'uyla çalıştır. İstemde yalnız: görev, kabul kriterleri, varsa spec, dokunulacak kodun dışa açık arayüzü (imzalar, API yolları). Onaylı planın uygulama ayrıntısını ve hazır test kodunu verme: test istenen davranışı sınar, planı değil. Ajan kabul testlerini (kimlik test adında: `Ö-01.1`) ve gerekiyorsa saldırgan testlerini yazar, çalıştırır ve **kırmızı** olduklarını gösterir; kırmızı çıktıyı bana göster. Belirsiz kriter raporlarsa soruyu sen sor. Test dosyalarına yalnız `test-writer` yazabilir: ana oturum ve kod ajanı denerse test koruması engeller.
-2c. **Kod rolüne devret (2c ve 3):** Akış "Kod: ana oturum" diyorsa (küçük görev: alt ajanın soğuk başlangıcı kazandırdığından pahalı) kodu adım 3'e göre kendin yaz. Yoksa Agent aracıyla alt ajan çalıştır, çağrıda kod rolünün `model` ve `effort`'unu ver. İstemde: görev ve kabul kriterleri, onaylı plan, dokunulacak dosyalar, adım 3'teki kurallar, 2b'nin kırmızı testleri (hedef: yeşile çevirmek; test dosyalarına dokunmaz). Alt ajan kullanıcıya soru soramaz: karar noktasında durup soruyu ve seçenekleri raporlamasını iste; soruyu sen sor, kararı günlüğe yaz, alt ajanı cevapla devam ettir. Düzeltme veya devam için de aynı alt ajanı SendMessage ile sürdür; yeni ajan başlatma (dosyaları yeniden okur). Raporu kısa iste (en fazla ~15 satır: değişen dosyalar, test sonucu sayıyla, açık sorular; kod ve tam çıktı yok). Alt ajan bitince diff'i ve test çıktısını kendin oku; adım 4'ten sonrası ana oturumda. Kullanıcıya görünen metni (humanizer) son haline sen getir.
-   **Test yanlış görünürse:** Kod tarafı testi değiştirmez. Nedenini raporlar; `test-writer`'ı SendMessage ile sürdür, kritere göre o karar versin. Kriter değişiyorsa bu bir karardır: kullanıcıya sor.
-3. Uygula. Kurallar:
-   - **Uygularken yeni bir karar noktası çıkarsa dur ve sor** (`docs/workflow/decision-protocol.md`). Tahmin edip devam etme.
-   - Skill'ler (`docs/workflow/skills.md`): Kod için `ponytail:ponytail`, kritik akış için `mattpocock-skills:tdd`. Arayüz için seçilen yön skill'i + `impeccable:impeccable` (`DESIGN.md`'ye bağlı kal; yeni tasarım kararı gerekirse `/design`). Kullanıcıya görünen metin için `humanizer:humanizer`.
-   - Sadece bu görevin kapsamı. Görev dışı sorunları düzeltme, `docs/workflow/progress.md` → "Açık sorunlar"a yaz.
-   - Kod haritası bağlıysa keşfi onunla yap; dosyaları toptan okuma. Büyük dosyada önce ara (grep), sonra yalnız gereken satır aralığını oku.
-   - Paket kurarken paket kapısı uyarırsa (uydurma / çok yeni / az kullanılan) kullanıcıya bildir; zorlamaya çalışma.
-   - Plan bayrak gerektiriyorsa özelliği bayrak arkasına koy ve `docs/operations/feature-flags.md`'ye ekle.
-   - Çalışırken limit %90 / %95 / %99'a gelirse `docs/workflow/usage-limits.md` §4'teki uyarıları ver; işi durdurma.
-   - Projedeki mevcut kalıpları kullan.
-   - Hata, boş ve yükleniyor durumlarını unutma.
-   - Kritik akışa dokunuyorsan (`docs/quality/test-plan.md`) test ekle.
-   - Yeni ortam değişkeni → `.env.example`.
-   - Yeni paket → kilit dosyası commit'e girer. Yeni sistem bağımlılığı (veritabanı, ffmpeg vb.) veya kurulum adımı → `README.md` → Gereksinimler / Kurulum.
-4. Doğrula: `node .claude/hooks/gate.mjs --run` (lint, tip kontrolü, test, Semgrep; görev sonu ve commit toplantısı bu çıktıyı kullanır). Kırmızı varsa düzelt. "Komut onayı gerekli" derse komutları bana göster; onaylarsam `node .claude/hooks/gate.mjs --approve`. Aynı hatada 2 denemede çözemezsen dur ve bana durumu anlat.
-5. **Kanıt üret.** "Çalışıyor olmalı" yetmez; çalıştığını göster. Yöntem `docs/architecture/stack.md` → "Doğrulama" bölümünde:
-   - Arayüz değişikliği → `node .claude/hooks/preview.mjs <görev kodu>`: dev sunucuyu açar, masaüstü (1440) ve mobil (390) ekran görüntüsünü `.previews/<görev kodu>/`'e yazar, sunucuyu kapatır. İlk çalıştırma Playwright indirmesi ve ilk derleme yüzünden birkaç dakika sürebilir: komuta 10 dakika zaman aşımı ver. Görüntüleri aç ve bana göster. Betik "komut onayı gerekli" derse komutları bana göster; onaylarsam `node .claude/hooks/gate.mjs --approve`. Başka bir hata verirse mesajı rapora yaz ve görüntüyü elle al. Sonra ilgili ekranda ana senaryoyu ve bir hata senaryosunu dene. Görevin arayüz kabul kriterlerini tarayıcıda kanıtlamak için raporda `/qa` öner.
-   - API/iş mantığı → gerçek istek at veya testi çalıştır; isteği ve yanıtı göster.
-   - Kanıt üretemiyorsan (cihaz, panel, ödeme gibi) bunu açıkça söyle ve benim yapmam gereken adımları yaz.
-6. Arayüz değiştiyse `impeccable:impeccable` → `critique` çalıştır; önemli bulguları düzeltip düzeltmeyeceğimi sor.
-6b. **Görev sonu kurul toplantısı** (`.claude/board/rules.md`; kurul kurulduysa). Bu, değişikliğin tek tam denetimidir: değişikliğe ilgili, akışın (2a) söylediği sayıda üye (en fazla 3) + `code-reviewer` (değişiklik auth, ödeme, kişisel veri gibi hassas bir yola dokunuyorsa `security-auditor` da), inceleme rolünün `model` ve `effort`'uyla. RET varsa görev bitmez; bulguyu ve seçenekleri sor. ONAY veya KOŞULLU ONAY ise ve kapı (adım 4) yeşilse `node .claude/hooks/commit-gate.mjs --approve "görev sonu: <katılanlar>"`: commit aynı değişiklikler için kurulu yeniden toplamaz, sonradan değişen dosyalar varsa yalnız onlar incelenir. Toplantıyı `docs/workflow/board.md` günlüğüne yaz. Kurul kurulmadıysa adım 9'da `/review-changes` öner.
-7. `AGENTS.md` → "Bitti tanımı" listesini tek tek kontrol et.
-8. Kapsam kalkanını kapat (komut kullanıcıya sorulur): `node .claude/hooks/freeze-guard.mjs --plan-end`. PRD'de sadece testi yeşil olan kriterleri işaretle. Testleri JUnit raporuyla çalıştır (`docs/architecture/stack.md` → Kabul testleri) ki pano güncellensin. Limiti tekrar oku. Roadmap, maliyet günlüğü ve progress yazımı mekaniktir, model çağrısı harcama; tek komutla yaz:
-   `node .claude/hooks/progress.mjs --done <görev kodu> --cost "<görev kodu> <kısa ad>" <K|O|B> --task "-" --did "<görev kodu>: <tek satır ne yapıldı>" --next "<sıradaki görev>" --check`
-   `--cost` başlangıcı adım 0'dan alır, bitişi ve süreyi kendisi hesaplar (masaüstünde `--limit <%>` ekle). `--check` progress.md'nin kalın etiketli satırlarını (durum çubuğu ve pano okur) denetler; bozuksa düzelt. Açık sorunlar ve bekleyen kararlar gibi düz metin bölümlerini gerekirse elle yaz.
-9. Rapor ver:
-   - Ne yapıldı (2-3 satır)
-   - Bu görevde alınan kararlar (kullanıcı / otomatik)
-   - Kanıt (ekran görüntüsü, istek/yanıt, test çıktısı)
-   - Benim nasıl test edeceğim (adım adım)
-   - Önerilen commit mesajı
-   - Kontrol edemediğin veya şüpheli olduğun yerler
-   - Görevde bir davranışını düzelttiysem ya da tercih söylediysem: aynı AskUserQuestion çağrısında ayrı bir çoklu seçim sorusu olarak "Tercih olarak kaydedeyim mi?" (AGENTS.md → kural 9, varsa; seçilenler `prefs.mjs --add`). Not yoksa sorma.
-   - Sonra ne yapalım? AskUserQuestion ile sor: commit (Önerilen; görev sonu denetimi geçerli, kurul kurulmadıysa önce `/review-changes`) / sıradaki göreve geç / bu görevde değişiklik iste. Commit'te hafif kurul denetimi otomatik istenir (commit kapısı hook'u). Commit atıldıktan ve testler yeşilken çalışan nokta kaydet: `node .claude/hooks/checkpoint.mjs --save "<görev kodu> bitti, testler yeşil"` (`/rollback` buraya döner).
-   - Commit atıldıysa: `docs/workflow/progress.md` → "Sıradaki adım" güncel mi bak, sonra tek satırla `/clear` öner (görev = oturum, `docs/workflow/usage-limits.md` §3; bağlam yüzdesinden bağımsız). Yeni oturum progress.md'den devam eder.
-   - Durum bloğu
+0. **Limit and context:** Read the limit and record the start: `node .claude/hooks/progress.mjs --start` (the desktop has no status line: pass `--limit <5-hour %>`, taken from `get_usage`). If context is past 50%, first suggest `/wrap-up` + `/clear`. If the level is yellow/red or the estimate exceeds the remaining share, say so in one line and start (`docs/workflow/usage-limits.md` §3; do not ask). If `docs/workflow/progress.md` → "Kaldığı yer" (where we left off) is filled, continue from there.
+0b. **Model and effort** (`docs/workflow/models.md`): Read the last choice with `node .claude/hooks/models.mjs --show`. There are five roles, one question per role (model and effort together, e.g. "Sonnet · high"; options are in models.md). Make two AskUserQuestion calls: first plan, code, test; then review, docs. In each question put the recommended option from models.md first, labeled "(Recommended)". If the last choice differs, write "last choice" in that option's description. In the test question, the recommended model differs from the code role's last choice (models.md). Save the answer with `node .claude/hooks/models.mjs --set plan=<model>:<effort> code=… test=… review=… docs=…`. If code and test use the same model, the script warns: pass the warning to the user. If the main session's model or effort differs from the plan role, suggest `/model <name>` and `/effort <level>` in one line. If the `maliyet` topic is closed in question mode, do not ask and do not run `--set`: the last choice stays valid; write "automatic" in the status block.
+1. Restate the task and its acceptance criteria to me in one sentence. Update the active task in `docs/workflow/progress.md`.
+2. If there is no approved plan for this task and it touches more than 2 files, first apply the `/plan-task` steps (including decision points), then wait for approval.
+2a. **Flow:** `node .claude/hooks/flow.mjs --files <number of files in the plan>` (the desktop has no status line: pass `--context` and `--limit` from `get_usage`). The output says where code and docs work run (main session / subagent), and how many members the end-of-task board uses and whether they meet in parallel or in sequence (re-run it at 6b: it suggests members by name from the changed paths). Steps 2c, 6b and 8 follow it. If it says "Suggest /clear first", suggest it in one line.
+2b. **Tests first, with a separate agent:** The code writer does not write the tests (AGENTS.md rule 7). Whatever the flow says, run the `test-writer` subagent with the test role's `model` and `effort`. Give the prompt only: the task, the acceptance criteria, the spec if any, and the public interface of the code to be touched (signatures, API paths). Do not give the approved plan's implementation details or ready-made test code: a test checks the requested behavior, not the plan. The agent writes the acceptance tests (criterion id in the test name: `Ö-01.1`) and, if needed, adversarial tests, runs them and shows that they are **red**; show me the red output. If it reports an unclear criterion, ask me the question yourself. Only `test-writer` can write to test files: if the main session or the code agent tries, the test guard blocks it.
+2c. **Hand off to the code role (2c and 3):** If the flow says "Kod: ana oturum" (code: main session; a small task: the subagent's cold start costs more than it saves), write the code yourself per step 3. Otherwise run a subagent with the Agent tool and pass the code role's `model` and `effort` in the call. Prompt: the task and acceptance criteria, the approved plan, the files to touch, the rules in step 3, and the red tests from 2b (goal: turn them green; it does not touch test files). A subagent cannot ask the user: at a decision point it must stop and report the question and options; you ask the question, write the decision to the log, and continue the subagent with the answer. Resume the same subagent with SendMessage for fixes or continuation too; do not start a new agent (it would re-read the files). Ask for a short report (at most ~15 lines: changed files, test result as numbers, open questions; no code and no full output). When the subagent finishes, read the diff and the test output yourself; step 4 onward runs in the main session. Put the user-visible text (humanizer) into its final form yourself.
+   **If a test looks wrong:** The code side does not change the test. It reports the reason; resume `test-writer` with SendMessage and let it decide per the criterion. If the criterion changes, that is a decision: ask the user.
+3. Implement. Rules:
+   - **If a new decision point appears while implementing, stop and ask** (`docs/workflow/decision-protocol.md`). Do not guess and continue.
+   - Skills (`docs/workflow/skills.md`): `ponytail:ponytail` for code, `mattpocock-skills:tdd` for critical flows. For UI, the chosen direction skill + `impeccable:impeccable` (stay bound to `DESIGN.md`; if a new design decision is needed, `/design`). `humanizer:humanizer` for user-visible text.
+   - Only this task's scope. Do not fix problems outside the task; write them to `docs/workflow/progress.md` → "Açık sorunlar" (open issues).
+   - If the code map is connected, explore with it; do not read files wholesale. In a large file, search first (grep), then read only the needed line range.
+   - If the package gate warns while installing a package (made-up / too new / rarely used), tell the user; do not try to force it.
+   - If the plan needs a feature flag, put the feature behind a flag and add it to `docs/operations/feature-flags.md`.
+   - If the limit reaches 90% / 95% / 99% while working, give the warnings in `docs/workflow/usage-limits.md` §4; do not stop the work.
+   - Use the existing patterns in the project.
+   - Do not forget error, empty and loading states.
+   - If you touch a critical flow (`docs/quality/test-plan.md`), add a test.
+   - New environment variable → `.env.example`.
+   - New package → the lock file goes into the commit. New system dependency (database, ffmpeg, etc.) or setup step → `README.md` → Requirements / Installation.
+4. Verify: `node .claude/hooks/gate.mjs --run` (lint, type check, test, Semgrep; the end-of-task and commit meetings use this output). Fix anything red. If it says "komut onayı gerekli", show me the commands; if I approve, run `node .claude/hooks/gate.mjs --approve`. If you cannot fix the same error in 2 attempts, stop and explain the state to me.
+5. **Produce evidence.** "It should work" is not enough; show that it works. The method is in `docs/architecture/stack.md` → "Verification":
+   - UI change → `node .claude/hooks/preview.mjs <task id>`: it opens the dev server, writes desktop (1440) and mobile (390) screenshots to `.previews/<task id>/`, and closes the server. The first run can take a few minutes because of the Playwright download and the first build: give the command a 10-minute timeout. Open the images and show them to me. If the script says "komut onayı gerekli", show me the commands; if I approve, run `node .claude/hooks/gate.mjs --approve`. If it gives another error, write the message in the report and take the screenshot by hand. Then try the main scenario and one error scenario on the relevant screen. To prove the task's UI acceptance criteria in the browser, suggest `/qa` in the report.
+   - API/business logic → send a real request or run the test; show the request and the response.
+   - If you cannot produce evidence (device, panel, payment, etc.), say so clearly and write the steps I must do.
+6. If the UI changed, run `impeccable:impeccable` → `critique`; ask me whether to fix the important findings.
+6b. **End-of-task board meeting** (`.claude/board/rules.md`; if the board is set up). This is the only full review of the change: the board members relevant to the change, in the number the flow (2a) says (at most 3), + `code-reviewer` (+ `security-auditor` if the change touches a sensitive path such as auth, payment or personal data), with the review role's `model` and `effort`. If there is a RET, the task is not done; ask with the finding and the options. If the verdict is ONAY or KOŞULLU ONAY and the gate (step 4) is green, run `node .claude/hooks/commit-gate.mjs --approve "görev sonu: <attendees>"`: the commit does not convene the board again for the same changes; if files changed afterward, only those are reviewed. Write the meeting to the `docs/workflow/board.md` log. If the board is not set up, suggest `/review-changes` in step 9.
+7. Check the "done" list in `AGENTS.md` → "Definition of "done"" one by one.
+8. Close the scope shield (the command asks the user): `node .claude/hooks/freeze-guard.mjs --plan-end`. In the PRD, check off only the criteria whose tests are green. Run the tests with a JUnit report (`docs/architecture/stack.md` → Acceptance tests and feature flags) so the dashboard updates. Read the limit again. Writing the roadmap, the cost log and progress is mechanical: do not spend model calls; write it with one command:
+   `node .claude/hooks/progress.mjs --done <task id> --cost "<task id> <short name>" <K|O|B> --task "-" --did "<task id>: <one line on what was done>" --next "<next task>" --check`
+   `--cost` takes the start from step 0 and computes the end and the duration itself (on the desktop add `--limit <%>`). `--check` validates the bold-labeled lines of progress.md (the status line and the dashboard read them); fix them if broken. Write plain-text sections such as open issues and pending decisions by hand if needed.
+9. Give the report:
+   - What was done (2-3 lines)
+   - Decisions made in this task (user / automatic)
+   - Evidence (screenshot, request/response, test output)
+   - How I should test it (step by step)
+   - Suggested commit message
+   - Places you could not check or are unsure about
+   - If I corrected your behavior or stated a preference during the task: in the same AskUserQuestion call, a separate multi-select question "Save as a preference?" (AGENTS.md → rule 9, if present; save the selected ones with `prefs.mjs --add`). If there are no notes, do not ask.
+   - Ask "What next?" with AskUserQuestion: commit (Recommended; the end-of-task review is valid; if the board is not set up, `/review-changes` first) / move to the next task / ask for changes in this task. At commit, a light board review is requested automatically (commit gate hook). After the commit is made and the tests are green, save a working point: `node .claude/hooks/checkpoint.mjs --save "<task id> done, tests green"` (`/rollback` returns here).
+   - If the commit was made: check that `docs/workflow/progress.md` → "Sıradaki adım" (next step) is current, then suggest `/clear` in one line (task = session, `docs/workflow/usage-limits.md` §3; independent of the context percentage). The new session continues from progress.md.
+   - Status block

package/.claude/commands/dashboard.md

@@ -1,25 +1,25 @@
 ---
-description: Projenin ayrıntılı durum raporunu verir ve dashboard.html panosunu yeniler.
+description: Gives the project's detailed status report and refreshes the dashboard.html dashboard.
 ---
 
-1. `node .claude/hooks/cost.mjs` (son 30 günün token ve maliyeti, ccusage) ve `node .claude/hooks/dashboard.mjs` çalıştır. Bu komut `dashboard.html` kontrol panelini üretir (her Claude cevabından sonra Stop hook'u da otomatik üretir; sayfa açıkken 30 sn'de bir yenilenir). Sekmeler: Genel, Yol haritası, Kararlar, Kurul, Bulgular, Kalite, Aktivite, Ürün ve teknik, Operasyon, Limit ve maliyet. Token ayrıntısı (en pahalı istekler, önbellek) için `/session-report`.
-2. Limiti oku (`docs/workflow/usage-limits.md` §1). `docs/workflow/progress.md`, `docs/product/roadmap.md`, `docs/decisions/log.md` ve `docs/workflow/board.md`'yi oku ve şu raporu ver:
+1. Run `node .claude/hooks/cost.mjs` (tokens and cost of the last 30 days, ccusage) and `node .claude/hooks/dashboard.mjs`. This command produces the `dashboard.html` control panel (the Stop hook also produces it automatically after every Claude answer; while the page is open it refreshes every 30 s). Tabs: Overview, Roadmap, Decisions, Board, Findings, Quality, Activity, Product and tech, Operations, Limit and cost. For token details (most expensive requests, cache) use `/session-report`.
+2. Read the limit (`docs/workflow/usage-limits.md` §1). Read `docs/workflow/progress.md`, `docs/product/roadmap.md`, `docs/decisions/log.md` and `docs/workflow/board.md`, and give this report:
 
 ```
-## Durum: [proje] · [tarih]
-**Aşama:** [aktif faz] · **Görev:** [aktif görev] · **İlerleme:** [biten/toplam görev]
-**Soru modu:** [...] · **Limit:** [5s % (sıfırlanma) · hf %] · **Kurul:** [durum, üye sayısı]
+## Status: [project] · [date]
+**Phase:** [active phase] · **Task:** [active task] · **Progress:** [done/total tasks]
+**Question mode:** [...] · **Limit:** [5h % (reset) · weekly %] · **Board:** [state, member count]
 
-**Bu aşamada biten:** [...]
-**Kalan görevler (bu faz):** [...]
-**Bekleyen kararlar:** [...]  ← varsa ilk sıraya koy
-**Açık sorunlar / riskler:** [...]
-**Son kararlar:** [son 5: soru → seçilen (kullanıcı/otomatik)]
-**Son kurul toplantıları:** [son 3: tür → sonuç, açık kritik]
-**Kaldığı yer:** [varsa]
-**Kontrol listeleri:** Güvenlik x/y · Canlıya alma x/y · KVKK x/y
-**Önerilen sıradaki adım:** [tek, somut komut]
+**Done in this phase:** [...]
+**Remaining tasks (this phase):** [...]
+**Pending decisions:** [...]  ← put first if any
+**Open issues / risks:** [...]
+**Latest decisions:** [last 5: question → chosen (user/automatic)]
+**Latest board meetings:** [last 3: type → result, open criticals]
+**Where we left off:** [if any]
+**Checklists:** Security x/y · Go live x/y · KVKK x/y
+**Suggested next step:** [one concrete command]
 ```
 
-3. Tarayıcı aracın varsa `dashboard.html`'i aç. Yoksa dosya yolunu ver.
-4. Bekleyen bir karar varsa raporun sonunda onu hemen sor.
+3. If you have a browser tool, open `dashboard.html`. Otherwise give the file path.
+4. If a decision is pending, ask it right away at the end of the report.