docs(partition): plan_disk_layout varsayımı gerçek parted ile çelişiyor — UYARI

28 Eyl 2026'da canlı ISO'ya SSH ile bağlanıp gerçek davranış ölçüldü.
msdos tabloda kernel offset'e göre sıralamıyor, MBR slot numarasını
aygıt adı yapıyor. Bu, plan_disk_layout'ın temel varsayımıyla
çelişiyor ve tersi durumda FAZ C korunan bölümü biçimlendirir.

Düzeltme YAPILMADI: önce GPT davranışı ölçülmeli (sda/sdb GPT) ve
kernel tablosu taze okumayla doğrulanmalı (partx yarım çalıştı,
reboot/ACPI yetkisiz).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

AGENTS.md

@@ -840,3 +840,62 @@ senaryoları dene:
 | `src/ui/buttons.rs` | `gradient_button` — `enabled: false` iken gri + `Sense::hover()` (tıklanamaz). Gradient butonlarda `add_enabled_ui` ÇALIŞMAZ, `*_button_enabled` gerekir. |
 | `src/lib.rs` | **SİLİNDİ** — çift crate root, `locales/` iki kez gömülüyordu |
 | `src/steps/display_manager.rs`, `netinstall.rs`, `license.rs` | dormant (derleniyor, sihirbaza bağlı değil) |
+
+---
+
+## 🛑 DOĞRULANMADI: `plan_disk_layout`'ın çekirdek varsayımı yanlış görünüyor
+
+**Durum: inceleniyor, düzeltme YAPILMADI.** 28 Eyl 2026'da canlı
+ISO'ya SSH ile bağlanıp gerçek `parted` + kernel davranışı ölçüldü.
+
+### Deney (sdc, 8 GiB, tamamen boş — test için kullanıldı)
+
+```
+1. mklabel msdos
+2. mkpart 1-101 MiB · 101-301 MiB · 301-5001 MiB
+3. rm 2                         → 200 MiB boşluk
+4. mkpart 5001-6001 MiB (1000 MiB)  → boşluğa SIĞMAZ
+```
+
+`parted` yeni bölümü **MBR slot 2**'ye yazdı. Kernel'in okuması:
+
+```
+/dev/sdc1  start=1 MiB     100 MiB     ← korunan
+/dev/sdc2  start=5001 MiB  1000 MiB     ← YENİ bölüm
+/dev/sdc3  start=301 MiB   4700 MiB     ← ESKİ bölüm (301 MiB'de AMA sdc3!)
+```
+
+`sdc3` **301 MiB**'de başlıyor ama 3 numarasını taşıyor; yeni bölüm
+**5001 MiB**'de başlıyor ama 2 numarasını. **Kernel offset'e göre
+sıralamıyor — MBR slot numarasını doğrudan aygıt adı yapıyor.**
+
+### Bu neden kritik
+
+`plan_disk_layout` (ve `AGENTS.md`'deki gerekçesi) varsayımı:
+*"parted rm N sonrası kernel bölümleri başlangıç offset'ine göre
+sıralayıp 1'den numaralandırır."*
+
+Gerçekte (MBR'da) öyle değil. O halde `plan_disk_layout` bu senaryoda
+`/dev/sdc3` öngörüyor; **gerçekte yeni bölüm `/dev/sdc2`**. `device_map`
+yanlış aygıtı gösterir → FAZ C **4700 MiB'lik KORUNAN bölümü** mkfs
+eder. Tam olarak `plan_disk_layout`'ın *önlemek için* yazıldığı
+veri kaybı.
+
+### Doğrulanmadan önce çözülecek iki soru
+
+1. **GPT davranışı ölçülmedi.** `sda` ve `sdb` **GPT**, ölçüm
+   **msdos** yapıldı. GPT'de kernel `efi_partition` diziyi LBA'ya göre
+   sıralıyor olabilir → iki tablo tipi farklı davranabilir. Ayırt edici
+   test hazırlandı ama tamamlanmadı: GPT giriş dizisi ile LBA sırası
+   farklı bir imaj (`/tmp/opencode/gpttest.img`) VM'e takılıp
+   kernel'in adlandırması okunacak.
+2. **Kernel tablosu taze miydi?** `partx -a` her çağrıda "error"
+   döndürdü ama tabloyu yine de güncelledi. `reboot` ve ACPI güç
+   düğmesi yetki yokluğu nedeniyle **çalışmadı** (`/proc/uptime`
+   değişmedi) → tazeden okuma ile doğrulanamadı. Bu VM'de
+   `BLKRRPART` izni yok.
+
+> ⚠️ Bu blok düzeltme DEĞİL, uyarıdır. `plan_disk_layout`'a
+> dokunmadan önce yukarıdaki iki soru cevaplanmalı; aksi hâlde
+> mevcut davranış ile "düzeltilmiş" davranış arasında hangisinin
+> doğru olduğunu bilemeyiz.

src/jobs/partition.rs

@@ -1282,6 +1282,54 @@ mod layout_tests {
         PhysicalExtent { num, start_mb: start, end_mb: end }
     }
 
+    /// ⭐ CANLI DOĞRULAMA — sdc'nin gerçek durumu.
+    ///
+    /// Durum `parted -s /dev/sdc unit MiB print free` çıktısından
+    /// alındı (canlı ISO, SSH ile):
+    ///
+    /// ```
+    ///   1      1.00MiB  101MiB   100MiB   primary
+    ///         101MiB   301MiB   200MiB            Free Space
+    ///   3      301MiB   5001MiB  4700MiB   primary
+    ///         5001MiB   8192MiB  3191MiB           Free Space
+    /// ```
+    ///
+    /// 2. bölüm silinmiş. Boşluk 200 MiB — 1000 MiB'lik yeni bölüm
+    /// **buraya SIĞMAZ**. Kod konumu kendisi hesapladığı için
+    /// diskin sonuna (5001 MiB) yazması ve 3. bölümün 2'ye kayması
+    /// gerekir.
+    #[test]
+    fn live_verified_sdc_oversized_new_partition() {
+        let physical = vec![phys(1, 1, 101), phys(3, 301, 5001)];
+        let destroyed = vec![2u32];
+        let creates = vec![(0usize, 1000u64)];
+
+        let (planned, remapped) =
+            plan_disk_layout("/dev/sdc", 8192, &physical, &destroyed, &creates)
+                .expect("planlanmalı");
+
+        assert_eq!(planned.len(), 1, "tek yeni bölüm planlanmalı");
+        let p = &planned[0];
+        println!(
+            "PLAN: {}MiB-{}MiB slot {} ({}), kayma {:?}",
+            p.start_mb, p.end_mb, p.num, p.device, remapped
+        );
+
+        // 200 MiB'lik boşluğa SIĞMAZ → disk sonuna yazılmalı
+        assert!(
+            p.start_mb >= 5001,
+            "boşluğa sığmayan bölüm disk sonuna konmalı, {}MiB yazıldı",
+            p.start_mb
+        );
+        assert_eq!(p.end_mb - p.start_mb, 1000, "istenen boyut korunmalı");
+        // Eski 3 numaralı bölüm 2'ye KAYMALI
+        assert!(
+            remapped.iter().any(|(old, new)| *old == 3 && new.contains("sdc2")),
+            "eski slot 3, sdc2'ye kaymalıydı; kayma listesi: {:?}",
+            remapped
+        );
+    }
+
     /// REGRESYON — asıl bulgu.
     ///
     /// `assign_partition_numbers` UI'da yeni bölüme "en küçük boş slot"u