# Review — docs/specs/sube-spec.md v0.5 — 20.10.2026

> **Review type:** spec-re-review
> **Previous review:** `docs/reviews/review-sube-spec-re-review-2026-10-20-r2.md` (heyet 817, APPROVED) — bu turda yalnız §9.1'e eklenen maddeler, kabul kriterleri 26–27 ve revizyon v0.5 değerlendirildi; diğer bölümler 817'de onaylı ve kilitli.
> **Upstream document(s) read:** `proje-haritasi.md` §4.4 satır 902–903 (20.10.2026 ek kararı: sıralı fatura numarası + belge, banka hesapları, yasal ibare, TCKN)
> **Other cross-referenced documents:** kod kanıtları — `database/migrations/2026_07_28_000400_create_reference_codes.php` (R-2: referans kodu bilerek rastgele), `database/migrations/2026_09_01_000200_create_invoices.php` (sütunlarda `reference_code_id` var, sıralı numara sütunu yok), `resources/js/pages/Office/Invoices/` (yalnız `Index.vue`, `Show.vue` — belge görünümü yok), `app/Support/Business/Settings.php:385-399` (`companyLetterhead()` yalnız `name/subtitle/address/phone` döner, vergi numarası yok), `app/Support/Shared/ReferenceCodes.php` (prefix mekanizması)
> **Stage locks in effect:** §1–§8, §9.2–§9.5, §10 (kriter 1–25 hariç bu turda dokunulan kısımlar), §11–§13'ün eski satırları, S-1…S-14 kilitli (817 APPROVED). Yalnız §9.1'in eklenen maddeleri ve kriter 26–27 bu turun kapsamıdır.

---

## Upstream Coverage Matrix

(Sıfırdan üretildi; yalnız bu turun kapsamındaki değişiklikler için.)

| Upstream § / madde | Reviewed doc'ta durumu | Kanıt |
|---|---|---|
| Ölçülen gerçek: `FT-2026-7K4M` rastgele referans kodu, yasal fatura numarası değil | ✓ | spec §9.1 ⚠ paragrafı; kod: `create_reference_codes.php` yorum bloğu "generated at random rather than counted up (R-2)" — doğrulandı |
| Ölçülen gerçek: fatura belgesi/çıktısı sistemde yok | ✓ | spec §9.1 ⚠ paragrafı; kod: `resources/js/pages/Office/Invoices/` yalnız `Index.vue`, `Show.vue` — ikisi de ekran, basılabilir belge görünümü yok, doğrulandı |
| Ölçülen gerçek: `company.*`'da vergi numarası alanı yok | ✓ | spec §9.1 ⚠ paragrafı; kod: `Settings::companyLetterhead()` yalnız `name/subtitle/address/phone` döndürüyor, doğrulandı |
| Harita 903: sıralı numara (3 harf şirket öneki + yıl + 9 hane), fatura belgesi şimdi, brief `fatura-belgesi-brief.md` | ✓ | spec §9.1 "Fatura numarası" ve "Fatura belgesi" paragrafları, kriter 26–27 |
| Harita 903: banka hesapları ve yasal ibare şirkette | ✓ | spec §9.1 "Şirket kaydı ayrıca..." paragrafı, kriter 27 |
| Harita 903: şahıs TCKN belgede açık | ✓ | spec §9.1 son TCKN paragrafı (AD-21/kırmızı çizgi 13'e bağlanmış), kriter 27 |
| **Zaten kesilmiş (mevcut) faturaların yeni sıralı numara alanı karşısındaki durumu** | ❌ | spec'te yok; §9.1 yeni numarayı "fatura kesildiği anda verilir" diye yalnız ileriye dönük tanımlıyor, geriye dönük faturalar için §9.3'ün "mevcut faturalar → merkez" dengiydeki bir karşılık yok → **F-1 (yeni)** |
| Fatura numarasının biçim teyidi (e-fatura ile uyumu) | ✓ (açık soru olarak doğru işaretlenmiş) | spec §9.1 "⚠ Biçim bilinen e-fatura biçimidir; muhasebeci teyidi Sets'tedir" — bu, spec'in kendi onayı değil Sets'in taşıdığı bir sorumluluk olarak doğru şekilde ayrılmış |

---

## ✅ What works

- **Spec, planın başında ölçülen gerçekle tutarlı şekilde kendi önceki varsayımını düzeltiyor** — bu tam olarak sürecin istediği şey: spec bir varsayımla yazılmış, implementasyon/plan aşamasında gerçek ölçülmüş, Sets karar vermiş, spec güncellenmiş. Üç ölçülen gerçeği (referans kodu rastgele, belge yok, vergi no alanı yok) kodla tek tek doğruladım — üçü de doğru.
- **§9.1'in yeni maddeleri §9.2'nin kilitlenmiş "kesildiği anda sabitlenir" kuralıyla tutarlı:** numara da şirket kimliği gibi kesim anında veriliyor ve iptal/yeniden kesim mekanizmasıyla uyumlu ("iptal edilen fatura numarasını korur, yeni numara yeniden kesilen faturanındır" — §9.2'nin "düzeltme iptal + yeniden kesim ile yapılır" kuralının doğal uzantısı).
- **Muhasebeci teyidi ayrımı doğru yapılmış:** spec kendi onayını vermiyor, "biçim bilinen e-fatura biçimidir; muhasebeci teyidi Sets'tedir" diyerek sorumluluğu doğru yere bırakıyor — spec'in kendi üstüne almaması gereken bir doğrulamayı almamış.
- Kriter 26–27 yeni maddelerin ölçülebilir karşılığı — numara biçimi, boşluksuzluk/tekrarsızlık, eşzamanlılık, iptal numarası koruma, belge görünümü, iptal işareti, TCKN + erişim logu — hepsi tek tek sayılmış.
- Bu turun değişikliği dar: yalnız §9.1 ve kriter 26–27 dokunulmuş, §9.2–§9.5 ve diğer bölümler harfiyen aynı; yeni bir çelişki üretecek yüzey sınırlı tutulmuş.

## ⚠️ Findings & Risks (in-scope for this review type)

**F-1 — Zaten kesilmiş faturaların yeni sıralı numara karşısındaki durumu tanımsız.** §9.1 yeni numarayı yalnız ileriye dönük tanımlıyor: "Fatura **kesildiği anda** verilir." Ancak sistemde bugüne kadar kesilmiş faturalar var (EGT-74 chunk 4'ten beri, `invoices` tablosu `reference_code_id` taşıyor, sıralı numara sütunu yok) ve bunların hiçbirinde sıralı numara yok — yalnız rastgele referans kodu var. §9.3 benzer bir geriye dönük durumu ("Mevcut faturalar → merkez") açıkça çözmüştü; §9.1'de **aynı düzeyde bir karşılık yok**. Bu, finansal doğruluk açısından boş bir köşe değil: Sets'in kendi cümlesi "biçim bilinen e-fatura biçimidir" diyor, yani sıralılık/boşluksuzluk yasal bir beklenti olabilir — mevcut faturalara geriye dönük numara verilirse bunlar kronolojik sıraya göre mi numaralanacak (ki bu, aralarında yeni kesilen faturalar varsa sıra karışıklığı yaratır) yoksa numarasız mı kalacaklar (ki bu da "her kesilmiş faturanın sıralı numarası olur" vaadini bozar)? Spec bu soruyu ne §9.1'de cevaplıyor ne de §11'e açık soru olarak taşıyor.

## ❓ Open Questions (to be answered before next stage)

1. (817'den devam eden, blocker değil) §12'deki "fiyat listesi tektir" satırı hâlâ tarih+alıntı formatını taşımıyor.

## Previous Findings Status

- 817 (APPROVED, 0 bulgu): bu turda dokunulmayan bölümler yeniden açılmadı, değişmedi.

## ⚠️ Upstream Findings

Yok.

## Verdict: ❌ REJECTED

Bu turun dar kapsamlı değişikliği ölçülen gerçeğe tutarlı şekilde uyarlanmış ve üç ölçüm de koddan doğrulandı; ancak matrix'te bir ❌ satır var: mevcut (geçmiş) faturaların yeni sıralı numara alanı karşısındaki davranışı tanımsız kalmış. Finansal doğruluk ve olası yasal sıralılık beklentisine dokunan bu boşluk, §9.3'ün zaten kurduğu "mevcut kayıt" deseninin burada tekrarlanmamasıdır ve plana sızarsa ya tutarsız bir geriye dönük numaralandırma ya da "bazı faturaların numarası yok" durumu üretir.