İşte zekâyla hiçbir ilgisi olmayan bir başarısızlık.
İyi temellendirilmiş bir yapay zekâ asistanından SkySpark'ta bir Spark kuralı oluşturmasını isteyin. Axon'u bilir. Fonksiyon kütüphanesi indekslenmiştir. Size temiz, sözdizimsel olarak geçerli bir kod yazar — ve elinize tek bir kayıt tutuşturur.
Çalışan bir Spark kuralının iki kayda ihtiyacı vardır: algılama mantığını taşıyan bir func kaydı ve kuralın nerede, nasıl uygulanacağını yapılandıran bir sparkRule kaydı. Bu ikisinin birbiriyle uyuşması gerekir. İkincisini atlarsanız hiçbir hata oluşmaz — elinizde yalnızca hiç tetiklenmeyen bir kural kalır, üstelik izlendiğini sandığınız bir sahada.
Hiçbir sözdizimi bilgisi bunu engellemez. Bu bir dil sorunu değil. Bu bir prosedür sorunu ve dışarıda bıraktığımız yarı tam da prosedür.
İş akışı aslında nedir
Bir iş akışı bir markdown dosyasıdır. Bütün numara bundan ibaret.
Kataloglanabilsin diye küçük bir frontmatter taşır, ardından tek bir işin düzgün biçimde nasıl yapılacağını anlatan sade düzyazı ve tablolar gelir:
---
title: Create Spark Rule
description: Step-by-step guide for creating a Spark rule with func and sparkRule records
category: fault-detection
tags: [spark, rule, fault, automation]
version: 1.0
---
Her iki MCP sunucusu da açılışta workflows/ dizinindeki her .md dosyasını yükler ve bunları Model Context Protocol üzerinden workflow:// URI'si altında okunabilir kaynaklar olarak sunar. Asistana bunların var olduğunun söylenmesi gerekmez — listeleyebilir, arayabilir ve iş sırasında talep üzerine tam metni çekebilir.
Fantom MCP Server bu dizini izler. İçine yeni bir dosya bırakın; yeniden derleme ya da yeniden başlatma olmadan kullanılabilir hâle gelir.
Bugünkü iki katalog
Fantom MCP Server — 13 iş akışı, inşa-ve-bakım tarafını kapsıyor:
ai-coding-loop · api-migration-reference · connector-workflow · create-pod · create-skyspark-extension · explore-code-relations · haxall-basics · haxall-coding-standards · haxall-methods-workflow · skyspark-4x-migration · unit-testing · use-fanr · xeto-spec-guide
Axon MCP Server — 10 iş akışı, analitik-ve-operasyon tarafını kapsıyor:
app-creation · axon-func-update · axon-lang-information · curRule-computed-points · html-email-skyspark · job-status-check · recform-template-design · spark-rule-creation · task-subscriber-permissions · visualytik-mcp-authoring
Yirmi üç dosya. Bu araç zincirinin şu anda kodlanmış prosedürel hafızasının tamamı bu — ve yeterli olmaktan çok uzak.
İyi bir iş akışı neye benzer
Amiral gemisi örnek ai-coding-loop; bir asistana kodu altındaki indeksin çürümesine izin vermeden nasıl değiştireceğini öğretir. Sunucunun yapısal hafızası 240'tan fazla projeyi ve 156.000'den fazla fonksiyonu kapsar; yeniden indekslenmeyen bir düzenleme, sonraki her aramayı sinsice yanlış hâle getirir.
Tüm döngünün dayandığı kural tek bir cümle: her kod değişikliğinden sonra, dokunduğunuz yollar için reindexChangedFiles çağırın. Yeniden ayrıştır, grafik düğümlerini ve kenarlarını yeniden kur, yeniden göm. Bunu atlarsanız bir sonraki anlamsal arama, artık var olmayan bir kod tabanından cevap verir.
Bu iş akışının ne olmadığına dikkat edin. Bir API'nin belgelendirmesi değil — bunu zaten araç açıklamaları yapıyor. Bu, işlem sırası; biri size söyleyince apaçık olan, söyleyene kadar da görünmez kalan şey.
O dosya ayrıca çalınmaya değer bir satır taşıyor: "10-06-2026'da sedonaWebEditor üzerinde canlı olarak doğrulandı." Doğrulama tarihi olan bir iş akışı, güvenebileceğiniz ya da emekliye ayırabileceğiniz bir iş akışıdır. Tarihi olmayan bir söylentidir.
Bu neden darboğaz
İlk sezgi, daha iyi modellerin bu boşluğu kapatacağını varsaymak. Kapatmıyorlar ve nedeni konusunda net olmakta fayda var.
Bir modelin bu alandaki zayıflığı muhakeme değil, giderek daha az da sözdizimi — temellendirilmiş indeksler sözdizimini hallediyor. Zayıflık şu: bina otomasyonundaki prosedürel bilgi, hiçbir şeyin yürütebileceği bir biçimde hiç yazıya dökülmedi. Dünya genelinde birkaç bin uygulayıcının kafasında yaşıyor ve çıraklıkla aktarılıyor: Bir Spark kuralının iki kayda ihtiyaç duyduğunu, kıdemli bir mühendis hiç tetiklenmeyen bir kural yayınladığınızı gördüğü için öğrenirsiniz.
Bu aktarım mekanizması ölçeklenmez ve insanlar iş değiştirdiğinde ayakta kalmaz. Her entegratör aynı prosedürleri bağımsız olarak yeniden türetir. Aynı öğleden sonra, paralel olarak, bir düzine şirkette kaybedilir.
Bir iş akışı, bir kez yazılan ve o andan itibaren her projede her asistan tarafından yürütülen o çıraklık anıdır.
Bunun neden topluluk işi olması gerekiyor
İşte tek başıma yapamayacağım kısım — ve tek bir şirket de yapamaz.
Bu bilgiyi elinde tutan insanlar çoğunlukla sunucu yazmıyor. Bir çatı tipi cihazın doğru devreye alma sırasını ya da hesaplanmış noktalarda hangi curRule deseninin gerçekten işe yaradığını bilen mühendis bir kontrol uzmanıdır — TypeScript geliştiricisi değil. Katkı vermek bir indeksleme motoruna pull request açmayı gerektirseydi, bu bilgi olduğu yerde kalırdı.
Gerektirmiyor. Bir iş akışı bir markdown dosyasıdır. Frontmatter, bir başlık, sırasıyla adımlar, tuzaklar. Nasıl yaptığınızı yazabiliyorsanız, bir iş akışı katkısı yapabilirsiniz.
Ekonomi saçma derecede bizim lehimize. Bir iş akışını yazmak bir öğleden sonranızı alır. Sonra da onu yeniden türetmek zorunda kalacak her mühendise bir öğleden sonra kazandırır — her şirkette, süresiz olarak. Yazılımda kaldıracın bu kadar dengesiz olduğu az yer vardır.
Üstelik bu alan parçalanamayacak kadar küçük. Bina otomasyonu web geliştirme değil; gelen bir katkıcı ordusu yok. Sedona, Haxall, Axon ve Xeto bilen insanların her biri prosedürlerini kendine saklarsa, herkes aynı öğrenim bedelini ödemeye devam eder. Yirmi üç dosya, bir avuç insanın başarabildiği kadarı. İncelenmiş ve tarihlendirilmiş iki yüz dosya, yeni gelen birinin ilk haftasında yapabileceklerini değiştirirdi.
Dürüst riskler
Bir iş akışı kataloğu kendiliğinden iyi olmaz; aksini varsaymak bu işi baştan başarısızlığa mahkûm eder.
Yanlış bir iş akışı, hiç iş akışı olmamasından kötüdür. Asistan onu kendinden emin biçimde izler ve kendinden emin biçimde yanlış bir sonuç üretir. Eksik prosedür en azından tereddüt üretir; kötü prosedür kötü devreye alma üretir. İnceleme burada çoğu belgelendirmede olduğundan daha önemlidir.
İş akışları sessizce eskir. SkySpark 4.0 eklenti formatını değiştirdi ve gerçek prosedürleri bir gecede geçersiz kıldı. Bir iş akışı yaşlandığını fark etmez. Bu yüzden frontmatter'da version: var; daha da iyisi, açık bir doğrulama tarihi ve en son hangi projede kontrol edildiği bilgisi.
Kapsam disiplini. Her şeyi anlatmaya çalışan bir iş akışı hiçbir şey öğretmez. İyi olanlar tek bir iş yapar — şunu oluştur, bunu taşı, indeksi taze tut.
Bunların hiçbiri yaklaşımın aleyhine değil. Hepsi; incelemenin, tarihlendirmenin ve yeniden doğrulamanın, iki yüz dosyaya ulaşıldığında sonradan eklenmek yerine en baştan işin parçası olması gerektiğini söylüyor.
Gelin kataloğu birlikte kuralım
Her iki sunucu da kaynağı erişilebilir durumda ve iş akışı dizinleri başlamak için mümkün olan en kolay yer:
- FantomMcpServer —
workflows/, 13 dosya, inşa-ve-bakım - AxonMcpServer —
workflows/, 10 dosya, analitik-ve-operasyon
Boşluklar hiç de ince değil. BACnet nokta adlandırma kuralları için bir iş akışı yok, bir soğutma grubu tesisi sekansını devreye alma için yok, her projenin baştan tartıştığı yarım düzine Haystack etiketleme kararı için yok.
Bu prosedürlerden birini biliyorsanız — nerede ters gittiği dahil, gerçekten biliyorsanız — bu bir iş akışıdır ve şu anda kimse onu yazıya dökmedi.
Onu, çalışma gruplarının koordine olduğu foruma getirin ya da iki depodan birine pull request açın. Markdown dosyası olması, eşiği bilerek alçak tutmak içindir.
Bu sunucuların nasıl çalıştığı hakkında daha fazlası: Axon MCP Server · diller arası kod zekâsı · Sidecar filosu ve RLM.