tillerhand 3.42.1 → 3.47.0

package/.claude/board/board-ux.md

@@ -1,44 +1,44 @@
 ---
 name: board-ux
-description: Uzman kurulu üyesi - UX ve Tasarım Uzmanı. Plan, görev sonu, commit ve faz sonu kurul toplantılarında kendi alanına giren değişiklikleri denetler ve karar önerisi verir. Kod değiştirmez.
+description: Expert board member - UX and Design Specialist. Audits changes in its own area in plan, task-end, commit and phase-end board meetings and gives a decision recommendation. Does not change code.
 tools: Read, Grep, Glob, Bash
 model: haiku
 ---
 
-Sen bu projenin uzman kurulunda **UX ve Tasarım Uzmanı** üyesisin. Arayüzün tutarlı, anlaşılır ve herkes için kullanılabilir olmasını sağlarsın. Impeccable'ın critique ilkeleriyle bakarsın.
+You are the **UX and Design Specialist** on this project's expert board. You make sure the interface is consistent, clear and usable for everyone. You review with Impeccable's critique principles.
 
-**Kesin kurallar:** Hiçbir dosyayı değiştirme. Bash'i sadece okuma için kullan (`git diff`, `git log`, test/lint komutları). `.env` dosyalarını okuma. Kendi alanında kal.
+**Hard rules:** Do not change any file. Use Bash only for reading (`git diff`, `git log`, test/lint commands). Do not read `.env` files. Stay in your own area.
 
-## Bu proje
+## This project
 
-<!-- Kurul kurulurken (/start Kurul adımı veya /board setup) doldurulur: ürünün tek cümlelik özeti, seçilen stack,
-     kritik akışlar ve bu rol için projeye özel riskler. Boşsa önce docs/product/prd.md ve docs/architecture/stack.md'yi oku. -->
+<!-- Filled in when the board is set up (/start board step or /board setup): one-sentence product summary, chosen stack,
+     critical flows and project-specific risks for this role. If empty, read docs/product/prd.md and docs/architecture/stack.md first. -->
 
-## Neye bakarsın
+## What you check
 
-- `DESIGN.md` belirteçleri dışında renk, boyut, boşluk veya bileşen kullanımı
-- Boş, hata, yükleniyor ve (mobilde) çevrimdışı durumları
-- Erişilebilirlik: kontrast, klavye erişimi, odak, etiketler, dokunma alanı
-- Bilgi hiyerarşisi, akış ve tek ana eylem kuralı
-- Metinler: hitap (`docs/product/glossary.md`), AI kokan kalıplar (humanizer'dan geçmiş mi?), belirsiz buton metinleri
-- Mobil genişlik ve koyu tema
+- Color, size, spacing or component use outside the `DESIGN.md` tokens
+- Empty, error, loading and (on mobile) offline states
+- Accessibility: contrast, keyboard access, focus, labels, touch target
+- Information hierarchy, flow and the single-primary-action rule
+- Copy: form of address (`docs/product/glossary.md`), AI-sounding patterns (did it pass humanizer?), vague button text
+- Mobile width and dark theme
 
-## Kaynakların
+## Your sources
 
-`docs/design/design-guide.md`, `DESIGN.md`, `PRODUCT.md`, `docs/product/glossary.md`. Kod haritası (codebase-memory-mcp) bağlıysa dosyaları toptan okumadan önce onu sorgula (`search_graph`, `trace_path`, `get_code_snippet`).
+`docs/design/design-guide.md`, `DESIGN.md`, `PRODUCT.md`, `docs/product/glossary.md`. If the code map (codebase-memory-mcp) is connected, query it before reading files in bulk (`search_graph`, `trace_path`, `get_code_snippet`).
 
-## Çıktı (kurul formatı; başka bir şey yazma)
+## Output (board format; write nothing else)
 
 ```
-ÜYE: UX ve Tasarım Uzmanı · KARAR: ONAY | KOŞULLU ONAY | RET
-BULGULAR:
-[KRİTİK|ÖNEMLİ|ÖNERİ] dosya:satır — sorun (somut senaryo) — öneri
-KULLANICIYA SORULMALI: [varsa kullanıcının vermesi gereken karar, seçenekleriyle tek satır]
-DİĞER ÜYELER İÇİN NOT: [alan dışı ama ciddi bir şey gördüysen tek satır]
+MEMBER: UX and Design Specialist · VERDICT: ONAY | KOŞULLU ONAY | RET
+FINDINGS:
+[KRİTİK|ÖNEMLİ|ÖNERİ] file:line — problem (concrete scenario) — suggestion
+ASK THE USER: [if any, the decision the user must make, one line with its options]
+NOTE FOR OTHER MEMBERS: [if you saw something serious outside your area, one line]
 ```
 
-- **RET** sadece KRİTİK bulgu varsa: güvenlik açığı, veri kaybı riski, yasal ihlal, kabul kriterinin karşılanmaması.
-- **KOŞULLU ONAY:** ÖNEMLİ bulgular düzeltilirse onay.
-- **Kapı çıktısı** (`gate.mjs`) verildiyse önce onu oku: kırmızı (❌) kontrol KRİTİK'tir, RET ver. Lint, tip ve testin zaten yakaladığını yeniden arama; yargı gerektiren konulara odaklan.
-- Bulgu yoksa `KARAR: ONAY` ve `BULGULAR: yok` yaz. Övgü, özet, uzun açıklama yok.
-- Emin değilsen bulguyu `[DOĞRULANMADI]` etiketiyle yaz ve nasıl doğrulanacağını söyle.
+- **RET** only when there is a KRİTİK finding: security hole, risk of data loss, legal violation, unmet acceptance criterion.
+- **KOŞULLU ONAY:** approve if the ÖNEMLİ findings are fixed.
+- **Gate output** (`gate.mjs`), if given: read it first. A red (❌) check is KRİTİK; give RET. Do not re-search what lint, types and tests already catch; focus on topics that need judgment.
+- No findings: write `VERDICT: ONAY` and `FINDINGS: none`. No praise, summary or long explanations.
+- If unsure, tag the finding `[UNVERIFIED]` and say how to verify it.

package/.claude/board/council.md

@@ -1,114 +1,114 @@
-# Konsey protokolü (üç aşama)
+# Council protocol (three stages)
 
-> Karpathy'nin llm-council yapısının kurula uyarlanmış hali (github.com/karpathy/llm-council).
-> 1. İlk görüşler bağımsız toplanır.
-> 2. Görüşler anonim olarak çapraz incelenir ve sıralanır.
-> 3. Bağımsız bir başkan sentezler.
+> The board-adapted form of Karpathy's llm-council structure (github.com/karpathy/llm-council).
+> 1. First opinions are collected independently.
+> 2. Opinions are cross-reviewed and ranked anonymously.
+> 3. An independent chair synthesizes.
 >
-> Sayım kodla yapılır (`node .claude/hooks/council.mjs`). Ana ajan oy saymaz ve başkan sayıyı değiştiremez.
+> Counting is done by code (`node .claude/hooks/council.mjs`). The main agent does not count votes and the chair cannot change the count.
 
-## Ne zaman
+## When
 
-Hangi toplantı ve kararın konseye gideceğini proje profili belirler (`docs/workflow/progress.md` → `**Profil:**`; `/start` Adım 0'da seçilir):
+The project profile decides which meetings and decisions go to the council (`docs/workflow/progress.md` → `**Profil:**`; chosen in `/start` Step 0):
 
-| | **Hafif** (Pro için önerilen) | **Standart** | **Tam** |
+| | **Hafif** (recommended for Pro) | **Standart** | **Tam** |
 |---|---|---|---|
-| Eklentiler | Çekirdek: ponytail, caveman, mattpocock-skills, impeccable, humanizer, security-guidance (+ tipin LSP ve stack skill'leri). Diğerleri proje kapsamında kapatılır | Hepsi açık | Hepsi açık |
-| Commit denetimi (her commit'te haiku kurul) | Kapalı | Açık | Açık |
-| Komut listesi (skill listesindeki açıklamalar) | 10 çekirdek komut açıklamalı, 18'i sadece adıyla | Hafif gibi | Hepsi açıklamalı |
-| Toplantı konseyi (3 aşama) | Yok; toplantılar tek aşamalı | Faz sonu, canlıya alma | Plan, faz sonu, canlıya alma, RET |
-| Karar konseyi | Veritabanı ve auth kararı | Veritabanı ve auth kararı | Tüm tek yönlü kararlar |
+| Add-ons | Core: ponytail, caveman, mattpocock-skills, impeccable, humanizer, security-guidance (+ the type's LSP and stack skills). The others are turned off at project scope | All on | All on |
+| Commit review (haiku board on every commit) | Off | On | On |
+| Command list (descriptions in the skill list) | 10 core commands with descriptions, 18 by name only | Like Hafif | All with descriptions |
+| Meeting council (3 stages) | None; meetings are single-stage | Phase end, go-live | Plan, phase end, go-live, RET |
+| Decision council | Database and auth decision | Database and auth decision | All one-way decisions |
 
-Ölçüm (2026-10-12): Bir konsey Pro'da 5 saatlik limitin yaklaşık %12'sini kullandı.
+Measurement (2026-10-12): One council used about 12% of the 5-hour limit on Pro.
 
-| Durum (profil izin veriyorsa) | Konsey türü | Aşama 1 üyeleri | Başkan |
+| Case (if the profile allows) | Council type | Stage 1 members | Chair |
 |---|---|---|---|
-| Plan, faz sonu, canlıya alma toplantısı | **Toplantı konseyi** | rules.md §3'e göre seçilen kurul üyeleri (inceleme rolünün modeliyle) | `board-chair` |
-| Görev sonu toplantısında RET çıktı | Toplantı konseyi (sadece aşama 2 ve 3) | RET veren üye + o toplantının diğer üyeleri | `board-chair` |
-| Tek yönlü kapı kararı (Hafif/Standart: sadece veritabanı ve auth; Tam: hepsi; `docs/workflow/decision-protocol.md` §2a) veya her profilde `/board council <soru>` | **Karar konseyi** | 3 × `council-advisor`: `haiku`, `sonnet`, `opus` (aynı soru, farklı model) | `board-chair` |
+| Plan, phase-end, go-live meeting | **Meeting council** | Board members chosen by rules.md §3 (with the review role's model) | `board-chair` |
+| RET in a task-end meeting | Meeting council (stages 2 and 3 only) | The member who gave RET + the other members of that meeting | `board-chair` |
+| One-way door decision (Hafif/Standart: database and auth only; Tam: all; `docs/workflow/decision-protocol.md` §2a) or `/board council <question>` in any profile | **Decision council** | 3 × `council-advisor`: `haiku`, `sonnet`, `opus` (same question, different model) | `board-chair` |
 
-- Görev sonu ve commit toplantıları tek aşamalı kalır (rules.md §4).
-- Limit sarıysa: karar konseyi 2 danışmanla (`sonnet`, `opus`) yapılır, toplantı konseyinde aşama 2'ye en fazla 3 üye katılır.
-- Limit kırmızıysa: konsey yerine tek aşamalı toplantı önerilir ve kullanıcıya sorulur.
+- Task-end and commit meetings stay single-stage (rules.md §4).
+- If the limit is yellow: the decision council runs with 2 advisors (`sonnet`, `opus`), and at most 3 members join stage 2 in a meeting council.
+- If the limit is red: suggest a single-stage meeting instead of a council and ask the user.
 
-## Tutanak
+## Minutes
 
-Her konsey tek bir dosyadır: `docs/workflow/council/YYYY-AA-GG-<tür>-<kısa-konu>.md`. Ana ajan aşamaların ham çıktısını buraya yazar. Bağlamı şişirmemek için sonraki adımlar tutanağı değil, dosya yolunu taşır.
+Each council is a single file: `docs/workflow/council/YYYY-AA-GG-<type>-<short-topic>.md`. The main agent writes the raw output of the stages here. To keep context small, later steps carry the file path, not the minutes.
 
 ```markdown
-# Konsey: <tür> · <konu>
-**Tarih:** 2026-10-12 · **Tür:** plan | faz-sonu | canliya-alma | ret | karar
-**Görev:** G-012 (varsa)
+# Konsey: <type> · <topic>
+**Tarih:** 2026-10-12 · **Tür:** plan | phase-end | go-live | reject | decision
+**Task:** G-012 (if any)
 
-## Soru
-<karar konseyinde: soru, seçenekler (her biri tek satır), bağlam dosyaları. Toplantıda: kapsam ve kabul kriterleri>
+## Question
+<decision council: the question, the options (one line each), context files. Meeting: scope and acceptance criteria>
 
 ## 1. İlk görüşler
 ### Görüş A
-- A1 [KRİTİK] dosya:satır — sorun — öneri
+- A1 [KRİTİK] file:line — problem — suggestion
 - A2 [ÖNEMLİ] ...
-ÖNERİ: <seçenek adı>          ← sadece karar konseyinde
+ÖNERİ: <option name>          ← decision council only
 ### Görüş B
 ...
 
 ## 2. Çapraz inceleme
 ### İnceleyen: A
-<her görüşün güçlü ve zayıf yanı, kısa>
+<strengths and weaknesses of each opinion, short>
 OYLAR:
 B1: DOĞRU | YANLIŞ | ABARTILI
-EKSİK: <kimsenin görmediği önemli bir şey varsa, tek satır>
+MISSING: <something important nobody saw, if any, one line>
 SIRALAMA:
 1. Görüş C
 2. Görüş B
 
 ## 3. Toplu sıralama
-<council.mjs yazar>
+<written by council.mjs>
 
 ## 4. Başkan kararı
-<board-chair yazar>
+<written by board-chair>
 
 ## Kimlikler
 A = board-architect (sonnet) · B = security-auditor (sonnet) · C = board-product (haiku)
 ```
 
-## Aşamalar
-
-1. **İlk görüşler (paralel).** Her üyeye kendi formatıyla görev verilir (toplantıda üye dosyasındaki kurul formatı, karar konseyinde `council-advisor` formatı). Gelen cevaplar rastgele sırayla A, B, C… etiketlenir. Bulgulara kimlik verilir: A1, A2, B1… Etiket-kimlik eşlemesi sadece tutanağın sonundaki "Kimlikler" bölümüne yazılır.
-2. **Çapraz inceleme (paralel).** Her inceleyene aşağıdakiler verilir ve aşağıdaki talimat aynen iletilir:
-   - Tutanağın "Soru" bölümü.
-   - Kendisi **hariç** diğer görüşler; kimin yazdığı ve hangi modelin yazdığı verilmez.
-   - Görüşler her inceleyene farklı sırada verilir (sıra etkisini azaltır).
-
-   > Aşağıdaki görüşleri kimin yazdığını bilmiyorsun. Her biri için ne iyi, ne eksik, iki cümleyi geçmeden yaz. Sonra her bulguya oy ver: DOĞRU (kanıtlı ve önem derecesi yerinde), ABARTILI (gerçek ama önemi düşük), YANLIŞ (kodda/bağlamda karşılığı yok). Oy verirken iddiayı kodda veya dokümanda kontrol et; tahminle oy verme. Kimsenin görmediği önemli bir şey varsa EKSİK satırına yaz. En sonda tam bu biçimle sırala: önce "SIRALAMA:" satırı, sonra en iyiden en kötüye "1. Görüş X" satırları, başka metin yok.
-
-   Toplantı konseyinde inceleyenler aynı üyelerdir. Karar konseyinde aynı danışmanlardır.
-3. **Sayım.** `node .claude/hooks/council.mjs <tutanak>` komutu şunları hesaplar ve tutanağa yazar:
-   - Ortalama sıra.
-   - Her bulgu için oy dağılımı.
-   - Tartışmalı bulgular: itiraz (YANLIŞ + ABARTILI) sayısı DOĞRU sayısına eşit veya fazlaysa.
-   - Uzlaşma yüzdesi.
-4. **Başkan.** `board-chair` (opus) çalıştırılır ve ona tutanağın yolu verilir. Başkan şunları yazar:
-   - Nihai kararı.
-   - Elenen bulguları ve gerekçelerini.
-   - Azınlık görüşünü.
-
-   Başkanın uyması gereken kurallar:
-   - Tartışmalı **KRİTİK** bulguyu kendi başına eleyemez. Bu bulgu "kullanıcıya sor" olarak kalır.
-   - RET kararı, en az bir KRİTİK bulgu tartışmalı değilse verilir.
-5. **Kullanıcı.** Ana ajan, başkanın kararını rules.md §4'teki sentez biçimiyle gösterir.
-   - Karar konseyinde AskUserQuestion seçenekleri konseyden gelir:
-     - Başkanın önerdiği seçenek ilk sırada ve "(Önerilen)" etiketli olur.
-     - Her seçeneğin açıklamasına "Konsey: n/N ilk görüş · ort. sıra x" eklenir.
-     - Azınlık görüşü kendi seçeneğinin açıklamasında tek cümleyle yazılır.
-6. **Kayıt.**
-   - `docs/workflow/board.md` → toplantı günlüğüne bir satır eklenir. Kapsam sütununa tutanak bağlantısı yazılır.
-   - Karar konseyi ise `docs/decisions/log.md` ve ADR'ye "Konsey: <tutanak>" referansı eklenir.
-
-## Neden
-
-- **Anonimlik:** Üye, otoritesi bilinen bir role (örn. güvenlik) körü körüne katılmaz.
-- **Çapraz oy:** Uydurma veya abartılı bulgular, kullanıcıya ulaşmadan elenir.
-- **Ayrı başkan:** Görüşü yazanla kararı verenin aynı model olmasını önler.
-- **Farklı modeller:** Aynı sorunun farklı yeteneklerle cevaplanmasını sağlar.
-
-Bir sınır var: Bütün üyeler Claude modelidir. Benzer kör noktaları paylaşabilirler. Konsey, kullanıcının kararının yerine geçmez.
+## Stages
+
+1. **First opinions (parallel).** Give each member the task in its own format (in a meeting, the board format in the member file; in a decision council, the `council-advisor` format). The replies are labeled A, B, C… in random order. Findings get ids: A1, A2, B1… Write the label-to-id mapping only in the "Kimlikler" section at the end of the minutes.
+2. **Cross-review (parallel).** Give each reviewer the following and pass the instruction below verbatim:
+   - The "Question" section of the minutes.
+   - The other opinions, **excluding** their own. Do not say who wrote them or which model wrote them.
+   - Give each reviewer the opinions in a different order (reduces order effects).
+
+   > You do not know who wrote the opinions below. For each one, write what is good and what is missing, in no more than two sentences. Then vote on each finding: DOĞRU (evidenced and severity is right), ABARTILI (real but low importance), YANLIŞ (no match in the code or context). When voting, check the claim in the code or docs. Do not vote on a guess. If nobody saw something important, write it on the MISSING line. At the end, rank in exactly this format: first the "SIRALAMA:" line, then "1. Görüş X" lines from best to worst, no other text.
+
+   In a meeting council, the reviewers are the same members. In a decision council, they are the same advisors.
+3. **Counting.** The command `node .claude/hooks/council.mjs <minutes>` computes the following and writes it to the minutes:
+   - Average rank.
+   - Vote distribution for each finding.
+   - `Tartışmalı` (contested) findings: when the number of objections (YANLIŞ + ABARTILI) is equal to or greater than the number of DOĞRU votes.
+   - `Uzlaşma` (consensus) percentage.
+4. **Chair.** Run `board-chair` (opus) and give it the path of the minutes. The chair writes:
+   - The final decision.
+   - The dropped findings and the reasons.
+   - The minority view.
+
+   Rules the chair must follow:
+   - The chair cannot drop a `Tartışmalı` **KRİTİK** finding alone. That finding stays as "ask the user".
+   - RET is given only if at least one KRİTİK finding is not `Tartışmalı`.
+5. **User.** The main agent shows the chair's decision in the synthesis format of rules.md §4.
+   - In a decision council, the AskUserQuestion options come from the council:
+     - The option the chair recommends comes first and is labeled "(Recommended)".
+     - Add "Council: n/N first opinions · avg. rank x" to each option's description.
+     - The minority view is written in one sentence in the description of its own option.
+6. **Record.**
+   - Add one line to `docs/workflow/board.md` → "Toplantı günlüğü" (meeting log). Write the link to the minutes in the scope column.
+   - For a decision council, add the reference "Council: <minutes>" to `docs/decisions/log.md` and to the ADR.
+
+## Why
+
+- **Anonymity:** A member does not blindly follow a role with known authority (for example security).
+- **Cross vote:** Made-up or exaggerated findings are dropped before they reach the user.
+- **Separate chair:** The one who wrote the opinion and the one who decides are never the same model.
+- **Different models:** The same question is answered with different abilities.
+
+One limit: All members are Claude models. They may share similar blind spots. The council does not replace the user's decision.

package/.claude/board/rules.md

@@ -1,83 +1,83 @@
-# Kurul Kuralları
+# Board Rules
 
-> Uzman kurulu, projeye özel ajanlardan oluşur (`.claude/agents/board-*.md` + `security-auditor`).
-> Üyeler ve toplantı günlüğü `docs/workflow/board.md`'de. Bu dosya kitindir ve toplantıların nasıl yapılacağını anlatır.
-> Rol şablonları bu klasörde (`board-*.md`); kurul kurulurken `.claude/agents/`'a kopyalanıp projeye özelleştirilir.
+> The expert board is made of project-specific agents (`.claude/agents/board-*.md` + `security-auditor`).
+> Members and the meeting log live in `docs/workflow/board.md`. This file belongs to the kit and says how to run meetings.
+> Role templates are in this folder (`board-*.md`). When the board is set up, they are copied to `.claude/agents/` and customized for the project.
 
-## 1. Yetki: danışman + kritikte durdurur
+## 1. Authority: advisor, and stops on critical findings
 
-- Kurul görüş, uyarı ve karar önerisi verir. **Kararı kullanıcı verir.**
-- Bir üye **RET** verirse (KRİTİK bulgu: güvenlik açığı, veri kaybı riski, yasal ihlal, kabul kriteri karşılanmadı) iş "bitti" sayılmaz ve commit edilmez. Kullanıcıya bulgu ve seçenekler sunulur: düzelt (önerilen) / riski kabul et ve gerekçeyi kaydet / görevi geri al.
-- Üyeler arasında görüş ayrılığı varsa ana ajan kendi başına seçmez; iki görüşü yan yana koyup kullanıcıya **karar olarak sorar**.
+- The board gives opinions, warnings and decision proposals. **The user decides.**
+- If a member gives **RET** (a KRİTİK finding: security hole, data-loss risk, legal violation, acceptance criterion not met), the work does not count as "done" and is not committed. Show the user the finding and the options: fix (recommended) / accept the risk and record the reason / roll the task back.
+- If members disagree, the main agent does not pick alone. Put both views side by side and **ask the user as a decision**.
 
-## 2. Toplantılar
+## 2. Meetings
 
-| Toplantı | Ne zaman | Kim katılır | Model |
+| Meeting | When | Who attends | Model |
 |---|---|---|---|
-| **Plan** | `/plan-task` sonunda, kullanıcı onayından önce | `board-product` + `board-architect` + değişikliğe ilgili üyeler (en fazla 4) | inceleme rolü (`docs/workflow/models.md`) |
-| **Görev sonu** | `/build` sonunda, "bitti" demeden önce | Değişikliğe ilgili üyeler (en fazla 3) | inceleme rolü (`docs/workflow/models.md`) |
-| **Commit (hafif)** | Her `git commit` öncesi (hook zorunlu kılar) | Değişen dosyalara ilgili en fazla 2 üye; sadece değişen satırları (diff) inceler | her zaman `haiku`, effort `low` |
-| **Faz sonu** | Faz bitince (`/wrap-up` önerir) veya `/board convene phase-end` | Tüm kurul | inceleme rolü (`docs/workflow/models.md`) |
-| **Canlıya alma** | `/release ilk` | Tüm kurul | inceleme rolü (`docs/workflow/models.md`) |
+| **Plan** | At the end of `/plan-task`, before user approval | `board-product` + `board-architect` + members relevant to the change (max 4) | review role (`docs/workflow/models.md`) |
+| **Task end** | At the end of `/build`, before saying "done" | Members relevant to the change (max 3) | review role (`docs/workflow/models.md`) |
+| **Commit (light)** | Before every `git commit` (a hook enforces it) | Max 2 members relevant to the changed files; reviews only the changed lines (diff) | always `haiku`, effort `low` |
+| **Phase end** | When a phase ends (`/wrap-up` suggests it) or `/board convene phase-end` | The whole board | review role (`docs/workflow/models.md`) |
+| **Go-live** | `/release ilk` | The whole board | review role (`docs/workflow/models.md`) |
 
-Sadece dokümantasyon değişikliği (`.md`, `docs/`) içeren commit'ler denetimden muaftır.
+Commits that contain only documentation changes (`.md`, `docs/`) are exempt from review.
 
-**Konsey (üç aşama):** Hangi toplantıların konseyle yapılacağını proje profili belirler (`.claude/board/council.md` → "Ne zaman"). Tam profilde plan, faz sonu ve canlıya alma toplantıları ile RET çıkan görev sonu toplantıları `.claude/board/council.md` protokolüyle yapılır; Standart'ta sadece faz sonu ve canlıya alma; Hafif'te hiçbiri. Önce ilk görüşler alınır, sonra üyeler birbirinin bulgularını anonim olarak oylar ve sıralar, en son `board-chair` karar verir. Görev sonu ve commit toplantıları tek aşamalıdır.
+**Council (three stages):** The project profile decides which meetings go to the council (`.claude/board/council.md` → "When"). In the Tam profile, plan, phase-end and go-live meetings, and task-end meetings that end in RET, follow the `.claude/board/council.md` protocol. In Standart, only phase-end and go-live. In Hafif, none. First opinions are collected first. Then members vote on and rank each other's findings anonymously. Last, `board-chair` decides. Task-end and commit meetings are single-stage.
 
-## 3. Kim ilgili? (değişikliğe göre üye seçimi)
+## 3. Who is relevant? (pick members by change)
 
-| Değişiklik | Üye |
+| Change | Member |
 |---|---|
-| Yeni özellik, kapsam, kullanıcı akışı | board-product |
-| Veri modeli, migration, yeni modül, yeni bağımlılık, klasör yapısı | board-architect |
-| Auth, yetki, ödeme, webhook, dosya yükleme, ortam değişkeni, sır | security-auditor |
-| Kişisel veri alanı, yeni dış servis, log içeriği, yasal metin | board-privacy |
-| Arayüz bileşeni, sayfa, ekran, metin | board-ux (+ web'de board-performance) |
-| API ucu, sözleşme, hata biçimi | board-api |
-| Test, kritik akış, hata düzeltmesi | board-qa |
-| CI, deploy, Docker, hosting, yapılandırma | board-devops |
-| Mobil izin, native modül, mağaza ayarı | board-mobile |
-| Prompt, model çağrısı, eval | board-ai |
-
-Görev sonunda `node .claude/hooks/flow.mjs` üyeleri değişen yollardan önerir (kurulda olanlar, en çok dosyası eşleşen önce; hassas yolda `security-auditor`). Yol tahmindir: değişikliğin anlamı farklıysa (yeni özellik → board-product gibi) tabloya göre düzelt.
-
-Kurulda olmayan bir üyeyi çağırma; ilgili alan kurulda yoksa durum bloğunda "kurulda X uzmanı yok" diye belirt.
-
-## 4. Toplantı nasıl yapılır
-
-1. **Limit kontrolü** (`docs/workflow/usage-limits.md`): Seviye sarıysa üye sayısını yarıya indir; kırmızıysa kullanıcıya sor (kurulu hafiflet seçeneği dahil). Görev sonu toplantısında üye sayısını ve paralel mi sırayla mı çalışılacağını `node .claude/hooks/flow.mjs` söyler (değişiklik büyüklüğü + limit; `code-reviewer` ve hassas yolda `security-auditor` her zaman katılır).
-1b. **Deterministik kapı** (commit, görev sonu, faz sonu; plan toplantısında yok): `node .claude/hooks/gate.mjs --run`. AGENTS.md → Komutlar'daki lint, tip kontrolü ve test ile Semgrep çalışır; sonuç değişiklik imzasıyla saklanır. Kırmızıysa veya boşsa (hiçbir kontrol çalışmadı) commit kapısı açılmaz: önce düzelt ya da Komutlar'ı doldur. Kullanıcı ara commit için açıkça isterse `node .claude/hooks/commit-gate.mjs --skip "kullanıcı isteği"` (her zaman onaya sorulur). Kapı "komut onayı gerekli" derse komutları kullanıcıya göster; onaylarsa `node .claude/hooks/gate.mjs --approve` (yeni veya değişen komut onaysız çalışmaz).
-1c. **Commit toplantısında önce** `node .claude/hooks/commit-gate.mjs --status`: "Onay geçerli" ise toplantı yok (görev sonu toplantısı aynı değişiklikleri denetledi). "Son onaydan sonra değişen: …" ise üyelere yalnız o dosyaların farkını ver.
-2. **Üyeleri paralel çalıştır** (Agent aracı, her üye ayrı alt ajan). Her üyeye şunları ver: toplantı türü, kapsam (plan metni / diff aralığı / faz), görev kodu, kabul kriterleri ve kapı çıktısı (varsa). Çağrıda inceleme rolünün `model` ve `effort`'unu ver (`node .claude/hooks/models.mjs --show`); commit toplantısında `model: "haiku"`, `effort: "low"` ver. Rapor sözleşmesini istemde yaz: en fazla ~15 satır ve 5 bulgu (fazlası tek satır: "diğer: N küçük bulgu"), bulgu başına tek satır, önem sırasıyla; övgü ve özet yok (raporlar ana oturumun bağlamına girer). İstem sırası: üyeler arasında aynı olan kısım (toplantı türü, kapsam, kabul kriterleri, kapı çıktısı) önce, üyeye özel kısım sonda; ortak baş önbellekten okunur. Düzeltmeden sonra yeniden bakılacaksa yeni üye başlatma: aynı üyeyi SendMessage ile sürdür ve yalnız düzeltilen farkı ver (soğuk başlangıç bir kez ödenir).
-2b. **Konsey toplantısıysa** (§2) `.claude/board/council.md` aşama 1-4'ü uygula. Sentezi başkanın kararından kur; görüş ayrılığı satırına azınlık görüşünü yaz.
-3. **Sentezle** (ana ajan; konseyde başkanın kararına göre):
+| New feature, scope, user flow | board-product |
+| Data model, migration, new module, new dependency, folder structure | board-architect |
+| Auth, authorization, payment, webhook, file upload, environment variable, secret | security-auditor |
+| Personal data field, new external service, log content, legal text | board-privacy |
+| UI component, page, screen, copy | board-ux (+ board-performance on web) |
+| API endpoint, contract, error format | board-api |
+| Test, critical flow, bug fix | board-qa |
+| CI, deploy, Docker, hosting, configuration | board-devops |
+| Mobile permission, native module, store setting | board-mobile |
+| Prompt, model call, eval | board-ai |
+
+At task end, `node .claude/hooks/flow.mjs` suggests members from the changed paths (only those on the board, the one with the most matching files first; `security-auditor` on a sensitive path). The path is a guess. If the meaning of the change differs (a new feature → board-product, for example), correct it using the table.
+
+Do not call a member who is not on the board. If the relevant area has no member, write "no X expert on the board" in the status block.
+
+## 4. How to run a meeting
+
+1. **Limit check** (`docs/workflow/usage-limits.md`): If the level is yellow, halve the member count. If red, ask the user (including the option to lighten the board). For a task-end meeting, `node .claude/hooks/flow.mjs` gives the member count and whether to run in parallel or in sequence (change size + limit; `code-reviewer` always attends, and `security-auditor` on a sensitive path).
+1b. **Deterministic gate** (commit, task end, phase end; not in the plan meeting): `node .claude/hooks/gate.mjs --run`. It runs the lint, type check and test from AGENTS.md → `Komutlar`, plus Semgrep. The result is stored with the change signature. If it is red or empty (no check ran), the commit gate does not open: fix first or fill in `Komutlar`. If the user explicitly asks for an intermediate commit, use `node .claude/hooks/commit-gate.mjs --skip "kullanıcı isteği"` (it always asks for approval). If the gate says "command approval required", show the commands to the user. If the user approves, run `node .claude/hooks/gate.mjs --approve` (a new or changed command does not run without approval).
+1c. **In a commit meeting, first** run `node .claude/hooks/commit-gate.mjs --status`. If it says "Approval valid", there is no meeting (the task-end meeting already reviewed the same changes). If it says "Changed since the last approval: …", give the members only the diff of those files.
+2. **Run the members in parallel** (Agent tool, each member as a separate subagent). Give each member: meeting type, scope (plan text / diff range / phase), task id, acceptance criteria and gate output (if any). In the call, pass the `model` and `effort` of the review role (`node .claude/hooks/models.mjs --show`). In a commit meeting, pass `model: "haiku"`, `effort: "low"`. Write the report contract in the prompt: max ~15 lines and 5 findings (any more as one line: "other: N minor findings"), one line per finding, in order of severity, no praise or summary (reports enter the main session's context). Prompt order: the part that is the same for all members (meeting type, scope, acceptance criteria, gate output) first, the member-specific part last; the shared head is read from cache. If a re-check is needed after fixes, do not start a new member. Continue the same member with SendMessage and give only the fixed diff (the cold start is paid once).
+2b. **If it is a council meeting** (§2), apply stages 1-4 of `.claude/board/council.md`. Build the synthesis from the chair's decision. Write the minority view on the disagreement line.
+3. **Synthesize** (main agent; in a council, from the chair's decision):
 
 ```
-## Kurul: [tür] · [kapsam]
-Katılan: [üyeler] · Sonuç: ONAY | KOŞULLU ONAY | RET
-Kritik: [varsa]
-Önemli: [birleştirilmiş, tekrarsız, önem sırasıyla]
-Görüş ayrılığı: [varsa iki görüş]
-Kullanıcıya sorulacaklar: [üyelerin işaretlediği kararlar]
+## Board: [type] · [scope]
+Attended: [members] · Result: ONAY | KOŞULLU ONAY | RET
+Critical: [if any]
+Important: [merged, no duplicates, in order of severity]
+Disagreement: [the two views, if any]
+To ask the user: [decisions the members flagged]
 ```
 
-4. **Kullanıcıyı bilgilendir ve sor:** Sorulacak kararları AskUserQuestion ile sor. Hangi bulguların düzeltileceğini **çoklu seçimle** sor; KRİTİK olanlar önerilen olarak işaretli olsun.
-5. **Kaydet:** `docs/workflow/board.md` → toplantı günlüğüne bir satır ekle. Kararları `docs/decisions/log.md` günlüğüne ekle. Açık kalan bulguları `docs/workflow/progress.md` → "Açık sorunlar"a yaz.
-6. **Commit toplantısı sonucu ONAY veya KOŞULLU ONAY ise** commit kapısını aç: `node .claude/hooks/commit-gate.mjs --approve "<katılan üyeler>"`. RET ise açma; önce kullanıcıya sor.
+4. **Inform the user and ask:** Ask the decisions with AskUserQuestion. Ask which findings to fix as a **multi-select**, with KRİTİK ones marked as recommended.
+5. **Record:** Add one line to `docs/workflow/board.md` → "Toplantı günlüğü" (meeting log). Add the decisions to the decision log `docs/decisions/log.md`. Write open findings to `docs/workflow/progress.md` → "Açık sorunlar" (open issues).
+6. **If the commit meeting result is ONAY or KOŞULLU ONAY,** open the commit gate: `node .claude/hooks/commit-gate.mjs --approve "<attending members>"`. If RET, do not open it; ask the user first.
 
-Kullanıcı commit denetimini o an için atlamak isterse açıkça söylemesi gerekir. O durumda `node .claude/hooks/commit-gate.mjs --skip "kullanıcı isteği"` çalıştır (onaya sorulur) ve günlüğe yaz. Kalıcı olarak kapatmak için: `docs/workflow/board.md` → `**Commit denetimi:** kapalı`.
+If the user wants to skip commit review for now, they must say so explicitly. Then run `node .claude/hooks/commit-gate.mjs --skip "kullanıcı isteği"` (it asks for approval) and write it to the log. To turn it off permanently: `docs/workflow/board.md` → `**Commit denetimi:** kapalı`.
 
-## 5. Kurul nasıl kurulur (`/start` Kurul adımı veya `/board setup`)
+## 5. How to set up the board (`/start` board step or `/board setup`)
 
-1. Proje tipine ve PRD'ye göre öneri (aşağıdaki tablo). AI eki varsa `board-ai`, kişisel veri varsa `board-privacy` mutlaka önerilir.
-2. Kullanıcıya **çoklu seçimle** sor (önerilenler işaretli). "Other" ile yeni bir uzman isteyebilir. Örneğin "Erişilebilirlik uzmanı", "Oyun tasarımcısı" veya "Fintech uyum uzmanı". Bu durumda mevcut şablon yapısıyla yeni bir `board-<ad>.md` yaz.
-3. Model sorulmaz: üyeler inceleme rolünün modeli ve effort'uyla çalışır (`docs/workflow/models.md`).
-4. Seçilen her üye için `.claude/board/board-<role>.md` dosyasını `.claude/agents/board-<role>.md`'ye kopyala ve **"Bu proje" bölümünü doldur**: ürün özeti, seçilen stack, kritik akışlar, bu role özel riskler. `security-auditor` zaten `.claude/agents/` altında.
-5. `docs/workflow/board.md` → durum, üye tablosu (Model sütununa "inceleme rolü") ve commit denetimi satırını doldur.
-6. Kullanıcıya kurulu tanıt: Her üye ne yapar, ne zaman devreye girer, tahmini maliyeti nedir (tek satır).
-7. Yeni ajanlar oturum yeniden başlatıldığında yüklenir. Kullanıcıya bunu söyle; bu oturumda gerekirse üyeyi genel amaçlı alt ajana rol dosyasının içeriğini vererek çalıştır.
+1. Recommend by project type and PRD (table below). If there is an AI add-on, `board-ai` is always recommended. If there is personal data, `board-privacy` is always recommended.
+2. Ask the user as a **multi-select** (recommended ones marked). With "Other" they can ask for a new expert, for example "Accessibility expert", "Game designer" or "Fintech compliance expert". In that case, write a new `board-<name>.md` using the existing template structure.
+3. Do not ask for a model: members work with the model and effort of the review role (`docs/workflow/models.md`).
+4. For each selected member, copy `.claude/board/board-<role>.md` to `.claude/agents/board-<role>.md` and **fill in the "This project" section**: product summary, chosen stack, critical flows, risks specific to this role. `security-auditor` is already under `.claude/agents/`.
+5. In `docs/workflow/board.md`, fill in the status, the member table (write "review role" in the Model column) and the commit review line.
+6. Introduce the board to the user: what each member does, when it steps in, the estimated cost (one line).
+7. New agents load when the session restarts. Tell the user this. In this session, if needed, run the member as a general-purpose subagent by giving it the content of the role file.
 
-| Tip | Önerilen kurul |
+| Type | Recommended board |
 |---|---|
 | web-saas | urun, mimar, security-auditor, ux, performans, kvkk, qa (+ devops, + ai) |
 | mobil | urun, mimar, security-auditor, ux, mobil, kvkk, qa (+ devops, + ai) |

package/.claude/claude-security-guidance.md

@@ -1,12 +1,12 @@
-# Bu kitle kurulan projeler için güvenlik rehberi
+# Security guidance for projects set up with this kit
 
-security-guidance eklentisinin model incelemeleri bu dosyayı ek kontrol listesi olarak okur. Projeye özel kurallar `docs/security/checklist.md`'de; burada sadece her projede geçerli olanlar var.
+The model reviews of the security-guidance plugin read this file as an extra checklist. Project-specific rules are in `docs/security/checklist.md`; this file holds only what applies to every project.
 
-- Supabase gizli anahtarı (`sb_secret_…`, eski `service_role`) ve her türlü gizli anahtar sadece sunucuda kullanılır; istemci koduna, `NEXT_PUBLIC_` / `EXPO_PUBLIC_` değişkenine girmez.
-- Supabase'de her tabloda RLS açıktır; yeni tablo RLS politikası olmadan eklenmez. Politika `auth.uid()` ile satır sahibini kontrol eder.
-- Her API ucu ve server action önce oturumu, sonra kaynağın sahibini kontrol eder (IDOR). İstemciden gelen `user_id` / `org_id` değerine güvenilmez.
-- Webhook'lar (ödeme, e-posta, üçüncü taraf) imza doğrulaması olmadan işlenmez; aynı olay iki kez gelirse iki kez işlenmez.
-- Kişisel veri (ad, e-posta, telefon, TC kimlik no, konum, sağlık) INFO veya üstü seviyede loglanmaz, hata izlemeye (Sentry) gönderilmez. KVKK.
-- Dosya yüklemede tür ve boyut sunucuda doğrulanır; yüklenen dosya herkese açık kovaya varsayılan olarak konmaz.
-- LLM çağrılarında kullanıcı girdisi ve dış içerik (web sayfası, belge) talimat olarak değil veri olarak ayrılır; modelin çıktısı doğrulanmadan SQL, kabuk komutu veya HTML olarak çalıştırılmaz.
-- Para, kredi, kota değiştiren işlemler sunucuda ve atomik yapılır; istemcinin gönderdiği fiyata güvenilmez.
+- The Supabase secret key (`sb_secret_…`, formerly `service_role`) and every other secret key are used only on the server; they never go into client code or a `NEXT_PUBLIC_` / `EXPO_PUBLIC_` variable.
+- In Supabase, RLS is on for every table; a new table is not added without an RLS policy. The policy checks the row owner with `auth.uid()`.
+- Every API endpoint and server action checks the session first, then the owner of the resource (IDOR). A `user_id` / `org_id` value that comes from the client is not trusted.
+- Webhooks (payment, email, third party) are not processed without signature verification; if the same event arrives twice, it is not processed twice.
+- Personal data (name, email, phone, national ID number, location, health) is not logged at INFO level or above and is not sent to error tracking (Sentry). KVKK.
+- On file upload, type and size are checked on the server; an uploaded file is not put in a public bucket by default.
+- In LLM calls, user input and external content (web page, document) are kept apart as data, not as instructions; model output is not run as SQL, a shell command or HTML without validation.
+- Operations that change money, credit or quota run on the server and are atomic; the price sent by the client is not trusted.