LABORATUVAR — KALİTE TESTİ & UYUMLULUK

Fabrikanın kalite bekçisi. Üretilen her kablo, bir sonraki üretim adımına geçmeden veya müşteriye gönderilmeden önce belirlenen aralıklarda laboratuvar testinden geçmelidir. Lab modülü Teknik (test standartları), Üretim (test talepleri) ve Kalite (geçti/kaldı ile ölçümler) arasında köprü kurar.

Şubat 2026 • Solen Kablo • Yaşayan Belge

1. LABORATUVAR NE YAPAR

Laboratuvar modülü, tüm üretim sisteminin bağımlı olduğu dört soruyu yanıtlar:

1. “Bu malzeme standartı karşılıyor mu?” — Her kablo tasarımı hangi testlerin yapılması gerektiğini ve hangi sıklıkta yapılacağını belirtir. Lab bu testleri yürütür ve tanımlı parametrelere göre nicel ölçümleri kaydeder.
2. “Üretim devam edebilir mi?” — Üretim sayfaları her 5 saniyede test durumunu yoklar. Belirli bir aralık için testler hala beklemedeyse veya başarısız olduysa operatör durumu görür. Tüm testlerin geçmesi sonraki adımın yolunu açar.
3. “Bir test başarısız olduğunda ne oldu?” — Başarısız testler otomatik olarak yeniden deneme talepleri oluşturur. Yeniden deneme zinciri parent_request_id ile takip edilir, böylece sistem bunun aynı çıkış için aynı testin 2. veya 3. denemesi olduğunu bilir.
4. “Uyumluluğu kanıtlayabilir miyiz?” — Her test sonucu, kapsadığı belirli üretim çıkışına (sepet/makara) kalıcı olarak bağlanır. Testler çıkışlara doğrudan (output_id) veya lot düzeyinde (linked_output_ids) bağlanır. Bu, bitmiş üründen her kalite kontrolüne kadar kesintisiz bir izlenebilirlik zinciri oluşturur.

2. VERİ AKIŞI

Lab modülü üç diğer modülün kesişim noktasında yer alır. Veri, Teknik ve Üretim’den Lab’a girer, sonuçlar ise Üretim’e ve bildirim sistemine geri çıkar.

2.1 Test Talebi Yaşam Döngüsü

2.2 Üç Test Aralığı

Bu aralıklar Lab modülünde sabit kodlanmış değildir. Kablo tasarımının material_details.tests[].frequency alanından gelirler ve virgülle ayrılmış değerleri destekler (örn. "üretim_başı,her_sepet_sonu" testin hem başlangıçta hem de her sepet sonunda çalışacağı anlamına gelir).

2.3 Test Başarısız Olduğunda Ne Olur

Tekrar deneme mekanizması otomatiktir. Lab kullanıcısı bir testi başarısız olarak işaretlediğinde, backend hemen retry_count = orijinal + 1 ve parent_request_id = orijinal.id ile yeni bir ProductionTestRequest oluşturur. Bu, tam denetim geçmişi için tekrar denemeleri birbirine zincirler. Yeni talep Lab’ın bekleyen kuyruğunda görünür ve üretim operatörü yüksek öncelikli bir bildirim alır.

2.4 Bildirim Köprüsü

3. VERİTABANI KATMANI

Lab modülü 5 tablo kullanır. İkisi temel test talebi tablolarıdır (eski + üretim entegreli), üçü Teknik modülünün test standartları sisteminden gelir.

3.1 production_test_requests (20 sütun) — Ana Tablo

Asıl iş yükünü taşıyan tablo budur. Üretim tarafından oluşturulan her test talebi burada yaşar.

3.2 test_requests (15 sütun) — Eski Tablo

Orijinal test talebi sistemi, geriye dönük uyumluluk için hala çalışır durumda. İş kartı/oturum bağlantısı yerine material_id ve material_qr kullanır. Durum enum’u farklıdır: test_bekleniyor, test_basarili, test_basarisiz, iptal. Üretim entegreli production_test_requests tablosu bundan sonra birincil sistemdir.

3.3 test_standards (Teknik modülünden)

Neyin test edileceğini tanımlar. Her standardın bir kategorisi (IEC-EN, UL, SLN), test adı, gerekli numune sayısı, test yöntemi ve parametre seti vardır. Lab, dinamik ölçüm formları üretmek için bunu okur.

3.4 test_parameters (Teknik modülünden)

Her test standardının bir veya daha fazla parametresi vardır. Bunlar lab’ın dinamik formunda görünen gerçek ölçüm alanlarıdır.

3.5 test_results (Teknik modülünden)

Kablo partilerine bağlı tarihsel test sonuçlarını saklar. pass_fail durumunu (PASS/FAIL/PENDING), measurements JSON’ını ve test standardı ile üretim oturumuna bağlantıları içerir.

4. BACKEND MİMARİSİ

4.1 Route Dosyaları

4.2 API Sözleşmesi — Üretim Test Endpoint’leri (9)

4.3 Eski Test Endpoint’leri (6)

4.4 Üretim Test Taleplerini Nasıl Oluşturur

Test talepleri Lab modülü tarafından oluşturulmaz. Oturum yaşam döngüsünün üç noktasında Üretim tarafından oluşturulur:

1. Oturum başlangıcı (POST /api/production/start-session): work_card.material_details.tests’i okur, üretim_başı frekansına göre filtreler, eşleşen test başına bir ProductionTestRequest oluşturur (paralel modda slot başına bir tane).
2. Çıkış kaydı (POST /api/production/record-output): her_sepet_sonu frekansına göre filtreler, belirli output_id’ye bağlı test talepleri oluşturur.
3. Oturum sonu (POST /api/production/end-session): üretim_sonu frekansına göre filtreler, test talepleri oluşturur, ardından lot düzeyindeki testleri (üretim_başı ve üretim_sonu) linked_output_ids aracılığıyla tüm ilgili çıkışlara bağlar.

4.5 Bağlı Test Sistemi

Testler üretim çıkışlarına üç şekilde bağlanır, bu sırayla kontrol edilir:

1. Doğrudan bağ: output_id çıkışla eşleşir — tek bir sepet/makaraya uygulanan her_sepet_sonu testleri için kullanılır.
2. Lot düzeyinde bağ: session_id eşleşir VE test_interval üretim_başı veya üretim_sonu — bu lot düzeyindeki testler oturumdaki tüm çıkışlara uygulanır.
3. Eski bağ: session_id eşleşir VE output_id IS NULL VE linked_output_ids IS NULL — eski test talepleri için geriye dönük uyumluluk.

GET /bonded-tests/output/{output_id} endpoint’i testleri aralığa göre gruplanmış olarak döner ve herhangi bir tek çıkış için eksiksiz kalite tablosu sunar.

4.6 Paralel Üretim Desteği

Bazı makineler (örn. OTOMEC Kalaylama, CGN E-beam) iki giriş yuvsıyla paralel işlemeyi destekler. Lab modülü bunu input_slot alanı (0 veya 1) aracılığıyla yönetir. Oturum başlangıcı ve sonunda, lot düzeyindeki testler için slot başına bir test talebi oluşturulur. Yuvaya özgü çıkışlar HalfProductStock’taki source_qr_codes ile bağlanır.

5. FRONTEND

5.1 Sayfa Yapısı

5.2 Test Sayfası — Temel Lab Arayüzü

Lab kullanıcılarının zamanlarının çoğunu geçirdiği yer burasıdır. 9 sütunlu bir ProTable’da tüm üretim test taleplerini gösterir ve tam test yaşam döngüsünü destekler.

ProTable Sütunları (9)

Dinamik Test Formları

Lab kullanıcısı “Test Başlat”a tıkladığında, sistem tüm parametreleri dahil tam test standardını GET /api/teknik/standards/tests/{id}/full’dan çeker. Form dinamik olarak üretilir:

• Her numune için (1’den test_samples’a): “Numune {n}” bölücüsü
• Her numune içindeki her parametre için: parametre adı etiket, birim ek olarak, min/maks sınırlar, adım 0.01 ve zorunlu bayrağı ile bir InputNumber alanı
• Altta bir notlar metin alanı
• Üç eylem düğmesi: İptal, Başarısız (tehlike), Onaylandı (birincil)

Ölçüm verileri yapılandırılmış JSON’a dönüştürülür: { samples: [{ sample_num: 1, params: { "Çap": 1.82, "Direnç": 9.45 } }] }

Gerçek Zamanlı Güncellemeler

Test listesi setInterval(fetchTestRequests, 5000) ile her 5 saniyede yoklar. Lab sayfası için WebSocket kullanılmaz — basitlik ve güvenilirlik için yoklama tercih edilmiştir.

Sonuç Görüntüleme

Tamamlanmış bir testte “Görüntüle”ye tıklamak, kompakt bir ölçüm tablosuyla salt okunur modal açar: sütun başlıkları parametre adları (birimlerle), satırlar numuneler, hücreler kaydedilen değerlerdir. Notlar tablonun altında gösterilir.

5.3 Dashboard — Genel Bakış Paneli

Şu anda 4 istatistik kartı (Bekleyen Uyarılar, Aktif Testler, Tamamlanan Testler, Bugünün Testleri) ve iki tablo (Bekleyen Lab Uyarıları, Aktif Test Süreçleri) gösterir. Tüm veriler şu anda sahte/sabit kodlanmış — Lab modülü olgunlaştıkça gerçek API’lere bağlanacak hazır bir kabuktur.

5.4 İstemci Taraflı Arama

Test sayfası şu alanlarda kapsamlı istemci taraflı arama filtrelemesi uygular: test kodu (L{id}), test adı, standart numarası, iş kartı ID, makine adı/tipi, aralık metni, test eden adı ve durum (Türkçe).

5.5 Yetki Sistemi

Test sayfasındaki kullanıcı tipi kontrolleri: isLabUser (lab_user veya super_admin) testleri başlatabilir/tamamlayabilir. isSuperAdmin test taleplerini silebilir. Normal kullanıcılar salt okunur erişime sahiptir.

6. LAB PANELİ (DASHBOARD)

6.1 Amaç

Lab Paneli, laboratuvar kullanıcıları için /lab/dashboard adresindeki giriş sayfasıdır. Amacı, lab’ın iş yükünün genel bir görünümünü sunmaktır: kaç uyarı bekliyor, kaç test aktif, kaç tanesi tamamlandı ve bugün ne oldu. Lab kullanıcısının giriş yaptıktan sonra gördüğü ilk sayfadır.

6.2 Mevcut Durum — Hazırlanmış Kabuk

Dashboard şu anda sahte verilerle hazırlanmış bir kabuktur. Tüm istatistikler ve tablo satırları sabit kodlanmıştır — hiçbir API çağrısı yapılmaz. Bu bilinçli bir tercihtir: düzen ve bilgi mimarisini tanımlamak için önce kabuk oluşturulmuştur ve Lab modülü olgunlaştıkça gerçek endpoint’lere bağlanacaktır. Bileşen, 133 satır temiz React kodundan oluşur, tamamen stillendirilmiş ve entegrasyona hazırdır.

6.3 Düzen ve Bileşenler

Sayfa, “Lab Kontrol Paneli” başlığını ve giriş yapmış kullanıcının adını gösteren kişiselleştirilmiş bir selamlama ile bir PageContainer sarıcısı içinde Ant Design grid sistemini kullanır.

İstatistik Satırı (4 kart)

Dört Statistic kartı duyarlı 4 sütunlu gridde (Col lg={6}), her biri ikon ve renk kodlu değerle:

Veri Tabloları (2 yan yana)

İstatistiklerin altında, iki tablo duyarlı 2 sütunlu düzende (Col lg={12}) yer alır:

Her tablonun bir eylem düğmesi sütunu vardır: uyarılar için “Test Başlat”, aktif testler için “Onayla”. Bu düğmeler şu anda işlevsiz yer tutuculardir.

6.4 Kimlik Doğrulama Entegrasyonu

Sahte olmasına rağmen, Dashboard zaten gerçek kimlik doğrulama sistemiyle entegredir. Giriş yapmış kullanıcının adını alt başlıkta göstermek için RealAuthService.getCurrentUser() çağrır. Rota, rota yapılandırmasındaki canLab yetkisiyle korunur.

6.5 Yol Haritası

Gerçek API’lere bağlandığında, Dashboard canlı verileri şuralardan çekecektir:

• GET /api/production/test-requests/all?status=pending → Bekleyen sayısı ve uyarı tablosu
• GET /api/production/test-requests/all?status=passed → Tamamlanan sayısı
• Test talebi zaman damgalarından toplu günlük istatistikler
• Bildirim sistemiyle gerçek zamanlı uyarı entegrasyonu

7. TEST YÖNETİMİ

7.1 Amaç ve Ölçek

Test Yönetimi, Laboratuvar modülünün operasyonel kalbidir. /lab/test adresinde yer alır ve lab kullanıcılarının fabrikanın çalıştırdığı her kalite testini aldığı, yürüttüğü ve kaydettiği yerdir. Frontend bileşeni 803 satır React/TypeScript, backend rota dosyası 745 satır Python/FastAPI’dir ve birlikte 9 üretim entegreli API endpoint’i ile 6 eski endpoint’i yönetirler. Üretim ve Lab arasındaki her etkileşim bu sayfa üzerinden akar.

7.2 Sayfa Başlığı ve Rozet

Sayfa başlığı “Test Talepleri”dir ve bir PageContainer içinde görüntülenir. Başlığın yanında canlı bir Badge bekleyen test sayısını gösterir. Bu rozet verilerle birlikte her 5 saniyede güncellenir ve lab kullanıcısına sayfa kaydırmadan anlık görsel bir iş yükü ipucu verir.

7.3 ProTable — 9 Sütunlu Test Kuyruğu

Sayfanın çekirdeği, yatay kaydırma (x: 1100), yerleşik sayfalama, yoğunluk geçişi, sütun görünürlük ayarları ve manuel yenileme ile yapılandırılmış Ant Design Pro ProTable’ıdır. Tablo GET /api/production/test-requests/all’dan 100’e kadar kayıt çeker ve 9 sütunda görüntüler:

7.4 İstemci Taraflı Arama

Araç çubuğu SearchOutlined ikonlu bir arama girdisi (200px geniş, yuvarlatılmış) görüntüler. Arama useMemo ile tamamen istemci taraflıdır: tüm veri setini 10’dan fazla alana karşı eş zamanlı filtreler:

• Test kodu (L{id})
• Test adı ve standart numarası
• İş kartı ID
• Makine adı (API’den) ve makine tipi (istemci taraflı eşlemeden)
• Aralık metni (Türkçe görüntü adları)
• Test eden adı
• Türkçe durum: “beklemede”, “onaylandı”, “başarısız”

7.5 Gerçek Zamanlı Yoklama

Bileşen yüklendiğinde fetchTestRequests()’i çağırır ve 5 saniyelik aralıklarla bir setInterval başlatır. Temizleme fonksiyonu sökülürken aralığı temizler. Bu, WebSocket karmaşıklığı olmadan neredeyse gerçek zamanlı güncellemeler sağlar. Üretim’den yeni bir test talebi geldiğinde tabloda 5 saniye içinde görünür.

7.6 Bildirim Derin Bağlantı Desteği

Bileşen yüklendiğinde useLocation() ile URL sorgu parametrelerini okur. Lab kullanıcısı bir bildirime tıkladığında (örn. “Test Talebi: Direnç Testi”), /lab/test?test_request_id=42’ye yönlendirilir. Sayfa bilgi mesajı gösterir: “Test talebi görüntüleniyor: #42”. Bu, bildirimden eyleme kesintisiz bir akış oluşturur.

7.7 Dinamik Test Formu

Lab modülünün teknik olarak en gelişmiş kısmı budur. Lab kullanıcısı bekleyen bir testte deney ikonuna tıkladığında, ortalı bir Modal (700px geniş, bulanık arka plan) açılır. Modal başlığı test adını, alt başlık olarak “İş Kartı #{work_card_id} • {aralık}” gösterir. Form tamamen test standardının parametre tanımlarından üretilir.

Adım 1: Test Standardını Getir

Sistem, parameter_order’a göre sıralanmış tüm parametreleri dahil tam test standardını almak için GET /api/teknik/standards/tests/{id}/full’u çağırır. Yüklenirken “Test standardı yükleniyor...” ile bir Spin bileşeni görüntülenir.

Adım 2: Form Alanlarını Üret

Form üretme algoritması test_samples (numune sayısı) × parameters (ölçüm alanları) üzerinde yineler:

Her numune için (1’den test_samples’a):
  Birden fazla numune varsa → "Çizgi" "Numune {n}" görüntüle
  test_standard.parameters içindeki her parametre için:
    InputNumber görüntüle:
      • ad: "sample_{s}_param_{param.id}"
      • etiket: parameter_name (örn. "Çap", "Direnç")
      • addonAfter: parameter_unit (örn. "mm", "Ω/km")
      • placeholder: "Hedef: {target_value}" tanımlıysa
      • parametre tanımından min/maks sınırlar
      • adım: 0.01
      • is_required bayrağı
      • flex düzen: 200px min genişlik, kaydırmalı

Bu, 3 parametreli ve 2 numuneli bir test standardının 2 numune grubu boyunca 6 giriş alanı ürettiği anlamına gelir. 1 parametreli ve 1 numuneli bir standart tek bir alan üretir. Form her zaman uyum sağlar — hiçbir iki test formu birbirine benzemez.

Adım 3: Uç Durumlar

• Parametre tanımlanmamış: “Bu test için parametre tanımlanmamış” mesajını yalnızca test adıyla gösterir. Kullanıcı yine de ölçüm olmadan testi geçirebilir/kalabilir.
• Standart bulunamadı: “Test standardı bulunamadı” gösterir.

Adım 4: Notlar Alanı

Tüm ölçüm alanlarının altında, “Notlar” etiketli ve “Test ile ilgili notlar...” yer tutuculu bir TextArea (2 satır) lab kullanıcısının gözlem eklemesine olanak tanır.

Adım 5: Eylem Düğmeleri

Altta flex satırda üç düğme:

7.8 Test Tamamlama ve Ölçüm Montajı

Lab kullanıcısı “Başarısız” veya “Onaylandı”ya tıkladığında sistem:

1. form.validateFields() ile tüm zorunlu form alanlarını doğrular
2. Dinamik alan adlarından ölçüm JSON’ını monte eder:

   {
     "samples": [
       { "sample_num": 1, "params": { "Çap": 1.82, "Direnç": 9.45 } },
       { "sample_num": 2, "params": { "Çap": 1.81, "Direnç": 9.52 } }
     ]
   }

3. POST /api/production/test-requests/{id}/complete’e { passed: true/false, measurements: {...}, notes: "..." } gönderir
4. Başarılıysa: “Test onaylandı” veya “Test başarısız” gösterir, modalı kapatır, formu sıfırlar, tabloyu yeniler

7.9 Başarısızlıkta Otomatik Tekrar Deneme

Backend passed: false tamamlaması aldığında, tek bir veritabanı işleminde üç şeyi atomik olarak yapar:

1. Orijinali günceller: Durumu FAILED yapar, test edeni, zaman damgasını ve ölçümleri kaydeder
2. Tekrar oluşturur: Aynı work_card_id, session_id, output_id, test_standard_id, machine_type ve test_interval ile yeni bir ProductionTestRequest — ancak retry_count = orijinal + 1 ve parent_request_id = orijinal.id
3. Bildirim gönderir: Orijinal talep edene ve tüm super admin’lere yüksek öncelikli bildirimler, test sayfasına derin bağlantı ve ek veride retry_request_id ile

Tekrar talebi 5 saniye içinde (sonraki yoklama döngüsü) Lab kuyruğunda yeni bekleyen test olarak görünür. API yanıtı retry_created: true ve retry_request_id içerir.

7.10 Tamamlanmış Test Sonuçlarını Görüntüleme

Tamamlanmış testler (geçti veya başarısız) için göz ikonu salt okunur bir Modal (480px geniş, bulanık arka plan) açar. Başlık, geçti/kaldı etiketiyle test adını, artı meta verileri gösterir: L{id} • #{work_card_id} • GG.AA SS:dd.

Sonuç görüntüsü kompakt bir ölçüm tablosu sunar:

• Başlık satırı: # sütunu (numune numarası) ardından parametre adı başına bir sütun, birim altında küçük metinle
• Veri satırları: Numune başına bir satır, her parametrenin altında hizalanmış monospace değerlerle
• Notlar: Lab kullanıcısı not yazdıysa tablonun altında gri kutuda görünür
• Ölçüm yok: Parametre ölçümü kaydedilmediyse “Parametre ölçümü kaydedilmemiş” gösterir

7.11 Silme İşlevi

Yalnızca super_admin kullanıcılar silme düğmesini (kırmızı çöp ikonu) görür. Tıklamak bir Popconfirm gösterir: “Silmek istediğinize emin misiniz?” Evet/Hayır seçenekleriyle. Onaylanan silmeler DELETE /api/production/test-requests/{id}’yi çağırır ve satırı iyimser bir şekilde state’den kaldırır.

7.12 Yetki Modeli

7.13 Backend: Üretim Test Taleplerini Nasıl Oluşturur

Test talepleri Lab modülünden değil, Üretim modülünden kaynaklanır. POST /api/production/test-requests/create-for-interval endpoint’i oturum yaşam döngüsünün üç noktasında çağrılır:

Frekans alanı virgülle ayrılmış değerleri destekler (örn. "üretim_başı,her_sepet_sonu"), yani tek bir test birden fazla aralıkta tetiklenebilir. Her eşleşen test için sistem, talebi oluşturmadan önce TestStandard’ın veritabanında var olduğunu doğrular.

7.14 Backend: “Tüm Testler” Endpoint’i

GET /api/production/test-requests/all endpoint’i Lab sayfasını besler. Tek bir sorguda 5 ilişkiyi eager-load eder (test_standard, work_card, session, requester, tester), durum filtrelemeyi destekler, varsayılan 50 ile sınırlar (frontend 100 ister), ve oturumun machine_id’sini machine_type için doğru makine tablosuna bakarak makine adlarını çözer. Yanıt ayrıca başlık rozeti için genel pending_count içerir.

7.15 Backend: Bağlı Test Sistemi

İki endpoint bağlı test sorgularına hizmet eder — çıkış ID’sine ve çıkış koduna (örn. X1, X2) göre. Belirli bir üretim çıkışına uygulanan tüm testleri aralığa göre gruplanmış olarak dönerler. Bağlama mantığı üç seviyeyi kontrol eder:

1. Doğrudan bağ: output_id eşleşir — belirli bir sepet/makaraya bağlı her_sepet_sonu testleri
2. Lot düzeyinde bağ: Aynı oturum + aralık üretim_başı veya üretim_sonu — bu lot düzeyindeki testler oturumdaki her çıkışa uygulanır
3. Eski bağ: Aynı oturum + output_id IS NULL + linked_output_ids IS NULL — geriye dönük uyumluluk

Yanıt testleri { "üretim_başı": [...], "her_sepet_sonu": [...], "üretim_sonu": [...] } şeklinde gruplar ve aralık başına sayılar içeren bir özet nesnesi ile. Bu, herhangi bir tüketiciye (Üretim sayfası, QR tarayıcı, raporlar) tek bir çıkış için eksiksiz kalite tablosu sunar.

7.16 CRUD Akışı

OLUŞTUR (Test Talebi)

1. Üretim operatörü oturum başlatır, çıkış kaydeder veya oturumu bitirir
2. Üretim backend’i work_card.material_details.tests’i okur
3. Mevcut aralığın frekansına göre filtreler
4. POST /api/production/test-requests/create-for-interval’i çağırır
5. Her eşleşen test için: PENDING durumlu ProductionTestRequest oluşturur
6. Tüm lab_user ve super_admin’e yüksek öncelikli bildirimler gönderir (talep eden hariç)
7. Yeni talep 5 saniye içinde Lab kuyruğunda görünür

OKU (Test Kuyruğu ve Sonuçlar)

1. Lab sayfası yüklenir → GET /api/production/test-requests/all?limit=100
2. Backend 5 ilişkiyi eager-load eder, makine adlarını çözer
3. Güncellemeler için her 5 saniyede yoklar
4. İstemci taraflı arama ek API çağrısı olmadan 10’dan fazla alanda filtreler
5. Bireysel test detayları: tam parametre listesiyle GET /api/production/test-requests/{id}
6. Çıkış başına bağlı testler: aralığa göre gruplanmış GET /bonded-tests/output/{id}

GÜNCELLE (Test Tamamlama)

1. Lab kullanıcısı bekleyen testte deney ikonuna tıklar
2. Sistem GET /api/teknik/standards/tests/{id}/full’dan parametrelerle tam test standardını getirir
3. Dinamik form görüntülenir: numuneler × parametreler → InputNumber alanları
4. Lab kullanıcısı ölçümleri doldurur, isteğe bağlı notlar ekler
5. “Onaylandı” (geçti) veya “Başarısız” (kaldı) tıklar
6. POST /api/production/test-requests/{id}/complete ile { passed, measurements, notes }
7. Backend doğrular: beklemede olmalı, kullanıcı lab_user/super_admin olmalı
8. Durumu günceller, tested_by, tested_at kaydeder, ölçüm JSON’ını saklar
9. Başarısızsa: atomik olarak tekrar talebi oluşturur (retry_count + 1, parent_request_id ayarlanır)
10. Talep edene + super admin’lere bildirim gönderir (geçti için orta, kaldı için yüksek öncelik)
11. Frontend tabloyu yeniler, modal kapanır

SİL

1. Super admin herhangi bir test talebinde çöp ikonuna tıklar
2. Popconfirm: “Silmek istediğinize emin misiniz?”
3. Onaylandı → DELETE /api/production/test-requests/{id}
4. Backend: super_admin doğrular, kaydı siler
5. Frontend: satırı iyimser bir şekilde state’den kaldırır

8. SONUÇ

Laboratuvar modülü kapsam olarak aldatıcı bir şekilde basittir — iki sayfa, beş tablo, on beş endpoint — ancak orantısız bir sorumluluk taşır. “Evet, bu kablo standartı karşılıyor” veya “hayır, durun ve yeniden test edin” diyebilen tek sistemdir. Onsuz, üretim çıkışları doğrulanmamış metaldir.

Üç tasarım kararı bu modülü tanımlar:

1. Testler Teknik’te tanımlanır, Üretim tarafından tetiklenir, Lab tarafından yürütülür. Bu sorumluluk ayrımı, kimsenin gerekli bir testi atlayamayacağı anlamına gelir — test gereksinimleri kablo tasarımının kendisine gömülüdür ve her üretim aralığında otomatik olarak uygulanır.
2. Formlar veriden üretilir, kodlanmaz. Dinamik form sistemi, yeni parametreler, birimler ve numune sayılarıyla yeni bir test standardı eklemenin sıfır frontend değişikliği gerektirdiği anlamına gelir. Form veritabanı tanımından görüntülenir, sistemi herhangi bir sayıda kalite standardına ölçeklenebilir kılar.
3. Başarısız testler kendi haleflerini oluşturur. parent_request_id zincirlemeyle otomatik tekrar mekanizması, başarısız bir testin asla unutulmamasını sağlar — kuyruğa hemen yeni bir bekleyen talep görünür ve tam tekrar geçmişi denetim için korunur.

Modül şu anda WebSocket yerine yoklama (5 saniyelik aralıklar) ile çalışır ve Dashboard sayfası sahte veri kullanır. Bunlar, erken dağıtım aşamasında basitlik ve doğruluğa öncelik veren bilinçli kararlardır. Mimari, fabrikanın test hacmi gerektirdiğinde gerçek zamanlı yükseltmelere ve canlı dashboard entegrasyonuna hazırdır.

Teknik (standartlar), Üretim (tetikleyiciler) ve Yönetim (yetkiler) ile birlikte Lab modülü, fabrikanın IEC-EN, UL ve özel SLN standartlarına uyumluluğu kanıtlamasına olanak tanıyan kalite güvence döngüsünü tamamlar — hammaddeden bitmiş kabloya.