Spesifikasyonunuzdaki her belirsizlik
ajanınızın yaktığı bir tokendir.

Olmadığında ne bozulur?

• 🌀 Spesifikasyonlar senkronizasyonunu kaybeder.

  Belgedeki spesifikasyon, Slack'teki tartışma ve PR'daki kod haftalarca sessizce birbirinden uzaklaşır. Kimse konuşmanın hangi sürümünün kanonik olduğunu bilemez.

  Çözüm

  Tek bir kanonik spesifikasyon; reponun içinde, kodla birlikte sürüm kontrolünde. specscore lint her push'ta CI üzerinde çalışır; git geçmişi denetim izidir. Spesifikasyon, tartışma ve PR sessizce ayrılamaz — inceleme altındaki aynı dosyayı paylaşırlar.

• 🌫️ Kabul kriterleri belirsiz kalır.

  "Hataları zarif bir şekilde ele al" ifadesi"bir toast mesajı göster ve geri al" anlamına mı geliyordu? Yoksa "logla ve yeniden dene" miydi? Ajan tahmin yürütmek zorunda kalır.

  Çözüm

  Linter, tek bir satır kod yazılmadan önce belirsiz kriterleri yakalar. Fiil linter'dan geçemez çünkü somut bir nesnesi veya koşulu yoktur. Uyarıyı çözmek, "ele al" ifadesinin gerçekte ne anlama geldiğini açıkça yazmanızı zorunlu kılar.

• 🤖 Ajanlar amaçlanmayan şeyleri teslim eder.

  İnsanlar yorumlar, soru sorar, netleştirir. Yapay zeka ajanları ise bunu yapmaz — eğitim verilerindeki en yaygın deseni uygularlar. Kod incelemeden geçer çünkü mantıklı bir şeyleryapıyordur. Yalnızca sizin amaçladığınız şey değildir.

  Çözüm

  Yapılandırılmış girdi. Yapay zeka ajanları REQ ID'lerini, AC ID'lerini ve GIVEN / WHEN / THENsenaryolarını deterministik olarak ayrıştırır — yorumlanacak hiçbir şey kalmaz. Her Plan görevi karşıladığı AC ID'lerine atıfta bulunmalıdır; böylece inşa edilen şey, belirtilen şeye karşı her zaman doğrulanabilir.

• 🔁 Belirsiz bir spesifikasyon için iki kat ödersiniz.

  Ajan belirsiz bir talimata dayanarak bir şeyler inşa eder, yanlış olduğunu görürsünüz ve dört farklı şekilde yeniden istersiniz. Yarım yamalak her özellik ve her yeniden deneme token olarak faturalandırılır. Spesifikasyon ne kadar belirsizse, doğru sonuca ulaşmak o kadar çok tur gerektirir.

  Çözüm

  Ajan çalışmadan önce spesifikasyonu lint edin.specscore lint belirsiz fiilleri ve eksik kabul kriterlerini en başından reddeder; böylece ajan denemeler arasında tahmin yürütmek yerine tek seferde somut bir talimatı uygular. En ucuz çalıştırma, tekrarlamak zorunda kalmadığınız çalıştırmadır.

• 💸 Ajanlar spesifikasyonlarınızı yeniden okumak için para harcar.

  "Bu özelliğe ne bağımlı?" sorusuna yanıt veren bir yapay zeka ajanı özelliğin tüm README'sini okur. Ardından her üst dizin indeksini. Ardından ne olur ne olmaz diye kardeş özellikleri. Her sorgu yeni bir ayrıştırmadır. Tokenlar erir, gecikme artar ve maliyet yükselir.

  Çözüm

  Dosya okuma yerine yapılandırılmış sorgular.specscore feature tree hiyerarşiyi YAML olarak döndürür;feature deps geçişli bağımlılık zincirini tarar;feature info durumu, sorumluyu ve açık soruları sunar — her biri tek bir çağrıda. Ajan düz metni değil, grafı dolaşır.

• 🔗 Kod spesifikasyonunu unutur.

  Altı ay sonra bir fonksiyonu debug ediyorsunuz ve kimse onun hangi özelliği uyguladığını hatırlamıyor. Kod ile spesifikasyon arasındaki bağ birinin aklındaydı ve o kişi artık şirkette değil. Onu getiren PR ise arşivlerde kayboldu.

  Çözüm

  Kaynak kod içi açıklamalar (annotations).// specscore: features/checkout/apply-discount/R1.AC-2gibi yorumlar bağı makine tarafından okunabilir kılar ve her refactoring'e dayanır. specscore code deps tek çağrıda"bu dosya hangi spesifikasyonu uyguluyor?" sorusunu yanıtlar; linter silinmiş spesifikasyonları gösteren referansları uyarır.

• 🏷️ Durum değişiklikleri gözden kaçar.

  Bir özelliği README dosyasında Draft durumundanApproved durumuna taşırsınız, ancak üst dizindeki features-index onu hala Draft olarak listeler. Üç hafta sonra indeksi okuyan bir ajan özelliğin hala incelemede olduğunu düşünür. Durum iki yerde yaşar ve birbiriyle çelişir.

  Çözüm

  specscore feature change-status özelliğin Status alanını yeniden yazar ve features-index satırını tek bir atomik adımda yeniden senkronize eder — lint başarısız olursa değişiklik geri alınır. Durum tek bir kanonik yerde yaşar; indeks bu durumun oluşturulmuş bir görünümüdür.

• 📋 Spesifikasyonlar bilmediklerini unutur.

  Bir spesifikasyon tamamlanmış gibi görünür — ta ki"peki saat dilimlerine ne oluyor?" sorusunun iki ay önceki bir Slack yazışmasında kaybolduğunu ve hiçbir zaman belgeye girmediğini hatırlayana kadar. Şimdi geliştirme aşamasındasınız ve kimse cevabın ne olduğunu bilmiyor.

  Çözüm

  Her SpecScore özelliğinin zorunlu bir Outstanding Questionsbölümü vardır. Linter bu bölümü atlayan özellikleri reddeder — boş olması kabul edilir ("None at this time."), ancak tamamen eksik olması reddedilir. Çözülmemiş sorular belgede görünür, CLI'dan sorgulanabilir ve unutulması imkansızdır.