Organizarea muncii Geliştirme ve gösterimler

Kararlaştırdığımız şey. Kimin devam ettiği. Sırada ne var.

Taskin, proje konuşmalarını ve bağlamını taahhütlere, önceliklere ve çalışma adımlarına dönüştürmeyi araştırır. Amaç, bir görev ile onun ortaya çıktığı konuşma arasındaki bağı korumaktır.

Discută o demonstrație Nasıl çalışıyor Bir örnek görün

1Discuție și context
2Sarcini propuse
3Angajamente confirmate

Schemă explicativă ·Taskin

Taskin

Bilgiden yapılmış işe.

Context

Proje için ilgili yetkili kaynakları bir araya getiriyoruz.

Angajamente

Ekibin doğrulaması için kararları ve yapılacak işleri belirliyoruz.

Continuitate

Onaylı adımların sorumluluklarını ve takibini düzenliyoruz.

Nerede faydalı olur.

Projeler

Bağlamı kaybetmeden kararların ve önceliklerin yeniden oluşturulması.

Întâlniri

Konuşmalardan çıkarılan görev önerileri, kullanımdan önce gözden geçirilir.

Operațiuni

İnsanlar ve AI ajanları arasında koordinasyon için bir yön.

İşlevler ve bağlantılar geliştirme aşamasında. Otomatik olarak çıkarılan herhangi bir kararın doğru ya da onaylı olduğunu varsaymıyoruz.

Taskin ayrıntıda

Bu proje ile neler yapabilirsiniz.

Taskin, bir özelliği olan bir çalışma panosudur: görevlerinizi girmesini beklemez. Daha önce ne olduğunu okur — aramalar, e-postalar, takvim, mesajlar, commitler, çalışma oturumları — ve bununla birlikte önerinin ortaya çıktığı kanıtla birlikte nelerin yapılması gerektiğini önerir.

Kurduğu ayrım, gözlemlenen ile kararlaştırılan arasındadır. Otomatik olarak önerilen bir görev, bir insan sorumlu kişiyi, son tarihi ve ifadeyi onaylayana kadar taahhüt haline gelmez. Bu kural bir arayüz vaadi değil, veritabanı tarafından dayatılan bir kısıtlamadır: bir ajan bir görevi kapatamaz ve bir görevi kapatan her yazım bunu kimin istediğini belirtmek zorundadır. İsimsiz bir yazım reddedilir.

Biz onu kendimiz için kullanıyoruz. Ondaki ilginç olan şeylerin neredeyse tamamı, kendi şirketimizin işletiminde somut bir şeye ihtiyaç duymamız nedeniyle ortaya çıktı; kod içindeki yorumlar ise gerçek üretim sayımlarını ve tarihli olayları alıntılıyor — bunlar arasında, günlük bir rutinin kimsenin haberi olmadan ardı ardına on bir gün sessiz kaldığı bir olay da var.

Deney değil, eksiksiz bir pano

49 sayfa üzerinde 50 rota: ekipler, döngüler, projeler, görevler, gelen kutusu, yol haritası, gün planı, dosyası ve geçmişi olan müşteriler, yinelenen giderler, faturalama, puantaj ve çalışma oturumları, performanslar, dahili sohbet, yönetim ve üyeler. Temel yapı, 81 migrasyondan oluşturulmuş 90 tabloya sahiptir.

Toplayıcı: gerçeği panoya taşıyan 21 döngü

Sunucuda zamanlanmış rutinler, işlem içi zamanlayıcılar değil — çünkü bir zamanlayıcı her yeniden dağıtımda kaybolur. Her çalışma, günlük yazan ve bir HTTP 200 yanıtı hata listesi taşıyorsa onu bile başarısız sayan, Telegram'da uyarı veren bir sarmalaktan geçer. Bu sarmalayıcı vardır çünkü daha önce sessizce başarısız olan bir komut günlük brifingi on bir gün boyunca ölü bıraktı.

MCP Sunucusu: insanlar ve ajanlar için aynı kuyruk

HTTP üzerinden 14 araç — okuma (listeleme, arama, benim kuyruğum, ajanların kuyruğu, board özeti, kişiler, ajanlar, projeler) ve yazma (oluşturma, güncelleme, atama, taşıma, yorum). Her erişim belirteci gerçek bir profile bağlıdır, bu yüzden board üzerindeki etkinlik bunu kimin talep ettiğini kaydeder. Bir AI ajanı ve bir ekip arkadaşı aynı liste üzerinde, aynı kurallarla çalışır.

Gerçek entegrasyonlar, adıyla anılan

Telegram, kendi botu olarak sürekli dinleme ile, sesli mesajların transkripsiyonu dahil. Dört e-posta kutusu (üç Gmail ve bir Microsoft 365), yalnızca okuma modunda okunur. Google Calendar. Telefon görüşmeleri, SIP trunk üzerinden, board tarafından başlatılan hatırlatma aramaları dahil. Obsidian. LinkedIn. Modeller OpenAI uyumlu kendi gateway’inden geçer, ajanların yürütme motoru ise OpenRouter üzerinde araç döngüsü kullanır.

Ajanların aşamayacağı kural

“Bir ajan bir görevi kapatmaz” veritabanında bir fonksiyondur, bir araç açıklamasındaki bir cümle değil. Oraya, ilk sürümün çalışmaması nedeniyle geldi: aktörü, otomatik bir hizmet için boş çıkan bir biçimde tanımlıyordu, bu yüzden kural hiçbir yerde uygulanmıyordu. Şimdi aktör üç ardışık kaynaktan çözümleniyor ve belirlenemezse, istek reddediliyor.

Veri ve çalışma

Sisteme ne girer. Ne doğrulanmalıdır.

Kuruluş bazında yalıtım, satır düzeyinde doğrulanır: 90 tablonun tamamında satır düzeyi erişim etkin, 171 politika altında. İç kural yazılıdır ve istisnasızdır: yeni bir tablo, onun için erişim politikası demektir. Rol hiyerarşisi Super Admin’den Admin, Membru ve Angajat’a gider.
Kaynaklar okunur, alınmaz: E-posta kutuları tasarım gereği okuma modunda bağlanır, yapılandırmadan değil. Çalışma oturumları ve git etkinliği kişinin bilgisayarından okunur, sunucudan değil. Board’a ulaşan şey, yazışmanın bir kopyası değil, kaynağa geri bağlantısı olan bir izdir.
Veriler kendi altyapımızda durur: Bizim tarafımızdan Azure üzerindeki bir makinede barındırılan Supabase, Supabase Cloud değil — Docker Compose içinde Postgres, Kong, Auth, Realtime ve Storage. Veritabanının adresi kendi alan adı üzerinde bir yoldur. Migrasyonlar bilerek manuel uygulanır: üretim şemasına dokunan otomatik bir adım yoktur.
Bir dil modeli ne görür: Özetleyen, bağlayan ve değerlendiren döngüler içeriği modellere gönderir. Dokuz iç döngüden dördü, credential eksik olduğunda açık bir günlük mesajıyla kendini devre dışı bırakır — yani bir anahtarın yokluğu akışı durdurur, onu yarım çalıştırmaz.

Keşiften uygulamaya

Taskin ile bir projeyi nasıl hazırlarız.

Tek bir kaynaktan ve tek bir projeden başlarız

Her şeyi bağlamıyoruz. Bir kaynak — genelde e-posta ya da Telegram — ve gerçek bir proje, böylece sistemin ne önerdiği ve önerdiklerinin ne kadarının yararlı olduğu gerçek veriler üzerinde görülebilsin.

Önerileri gerçek kararlarla karşılaştırırız

Sistemin önerdiği ve ekibin sadece onaylayıp reddettiği dönem, devam etmeye değip değmediğini gösteren dönemdir. Reddedilen bir öneri, kabul edilen kadar bilgilendiricidir.

Kapanış ve atama kurallarını yerleştiriyoruz

Kim neyi kapatabilir, bir terimin ne anlama geldiği ve sorumlusu olmayan bir görevle ne olduğu. Burada ayrıca ajanların board’a yazmasına izin verilip verilmediği ve hangi koşullarda verildiği de kararlaştırılır.

Kabul edilen altyapı üzerine kuruyoruz

Teslimat rsync ile bir makineye yapılır, konteynere değil: arayüz nginx tarafından sunulan statik dizinler olarak, toplayıcı ve MCP sunucusu ise systemd servisleri olarak. Sağlık denetimi, sunulan paketi derlenen paketle karşılaştırır ve uyuşmazlarsa geri alır.

Netleştirilmesi gereken sorular.

Bu tamamlanmış bir ürün mü, yoksa bir демонстрация mı?

Üretimde çalışıyor ve şirketimizi yönettiğimiz board o. Rakamlar: 566 commit, sonuncusu 4 Eylül 2026 tarihinde; 90 tablo oluşturan 81 migrasyon; satır düzeyinde 171 erişim politikası; 38 dosyada 563 otomatik test vakası; sunucuda planlanmış 21 rutin artı işlem içinde 9 döngü; 14 MCP aracı; toplayıcı üzerinde 35 endpoint. Ne değil: self-servis bir hizmet. Dışarıdaki bir ekibin onu kendi başına başlatacağı bir düğme yok — kurulur.

Kimlerin çalışacağını otomatik olarak mı belirliyor?

Hayır, ve kısıt veritabanında, arayüzde değil. Bir guard fonksiyonu bir ajanın bir görevi kapatmasını engeller, ve birini kapatan her yazma işlemi aktörü bildirmek zorundadır; aktör belirlenemezse istek reddedilir. Kuralın neden böyle göründüğünü de söylemek gerekir: ilk sürüm aktörü, otomatik bir hizmet için boş dönen bir fonksiyonla belirliyordu, dolayısıyla hiçbir yerde uygulanmıyordu. Dahili bir denetim bunu buldu ve düzelten migrasyon, yorumda tam olarak neyin çalışmadığını açıklıyor.

Somut olarak neye bağlanıyor?

Gerçekte, kod ve zamanlanmış rutin ile: Telegram (kendi botu, sürekli dinleme, sesli mesajların transkripsiyonu), üçü Gmail ve biri Microsoft 365 olmak üzere dört posta kutusu — yalnızca okunur, Google Calendar, SIP trunk üzerinden telefon görüşmeleri, Obsidian, LinkedIn, ayrıca kişinin bilgisayarından okunan çalışma oturumları ve git etkinliği. Modeller OpenAI uyumlu kendi gateway’imizden geçer; ajanların yürütme motoru OpenRouter üzerinde çalışır. Bağlı OLMAYAN şeyler ise, entegrasyon sayfamız onları gösterse de şunlardır: Slack, GitHub, Jira, Notion, Figma, Zapier, Dropbox, Google Drive, Microsoft Teams, GitLab, Outlook. Kodu aradık ve bunların hiçbiri için tek satır yok. O sayfa bir pazarlama tablosudur ve düzeltilmelidir.

WhatsApp entegrasyonu var mı?

Hayır, uygulamadaki bir ekranın adına rağmen. O ekran aslında bir cihazın QR kod ile eşleştirilmesidir, insanların WhatsApp Web’den alışık olduğu tarzda — adını oradan alır. Herhangi bir WhatsApp API’sine çağrı yoktur. Daha da fazlası: o akış kullanılmıyor ve tabloları boştur; bunu izinlerini revize eden migrasyon bile tespit eder.

Beyanların ötesinde güvenlik nasıl?

Faydalı olan, erişim politikalarımızın olması değil, açıklarını bulup tek tek onarmış olmamız; her migrasyon neyin çalışmadığını açıklıyor. Ağustos ayındaki dahili bir denetim, ajanlar için üç guard’ın da etkisiz olduğunu ortaya çıkardı. Başka bir guard fail-open çıkmıştı — kontrol tamamen atlanıyordu, reddedilmiyordu — ve fail-closed olacak şekilde tersine çevrildi. Üçüncü sorun daha ince ve geneldi: Postgres’te yeni bir fonksiyon varsayılan olarak herkes tarafından çalıştırılabilir, dolayısıyla açıkça yetki vermek hiçbir şeyi sınırlamıyordu; üretimde anonim bir anahtarın fonksiyon gövdesine ulaştığı doğrulandı, ardından varsayılan izin iptal edildi. Depo düzeyinde bir guard, ana dala doğrudan push’ları reddeder ve secret dosyalarını engeller; çünkü kişisel hesaptaki özel bir depo, GitHub tarafından dal korumasına sahip olamaz.

Ne tamamlanmadı?

Söylemeyi tercih ettiğimiz üç şey. Veritabanı için üretilen tipler ocaktan beri eski ve tamamen ilgisiz bir projeden tablolar içeriyor; bu da 26 dosyada 101 zorunlu tip dönüşümüne yol açtı — çalışıyor, ama tam da faydalı olacağı yerde derleme zamanındaki kontrolü kaybediyor. Stil denetleyicisi 161 miras hata bildiriyor ve teslimatı engellemiyor. Ve 36 test, orada olmayan bir model anahtarına ihtiyaç duydukları için sürekli entegrasyonda atlanıyor. Bunların hiçbiri ürünü durdurmuyor; üçü de gerçek borçtur.

Nasıl kurulur ve teslimat ne kadar güvenli?

rsync ile, container değil: arayüz nginx tarafından sunulan statik bir dizine gider, toplayıcı ve MCP sunucusu systemd servisleri olarak çalışır. Sürekli entegrasyon testleri çalıştırır ve derler; teslimat, bunlar ana dalda geçtiyse yalnızca kendi yürütücüsü üzerinden başlar; bu yürütücü yalnızca tam iki scripti çalıştırmaya yetkilidir, başka hiçbir şeyi değil. Pipeline’daki her dış eylem, bir etiket üzerinden değil, tam fingerprint’i üzerinden sabitlenmiştir; bu, Mart 2026’da popüler bir eylem ele geçirildikten sonra yapılmıştır. Sağlık kontrolü, servis edilen sayfanın referans verdiği paketi okur ve en güncel olan o değilse geri alır — bu kural 3 Eylül 2026’daki gerçek bir olaydan sonra yazıldı. Veritabanı migrasyonları bilinçli olarak manuel kalır.

İllüstratif örnek

Bir telefon görüşmesi, eki olan bir görev olur

Müşteri verisi veya atfedilen ticari sonuçlar olmadan bir kullanım senaryosu.

İlk durum

Bir arama bir vaatle biter. Bunu kimse hiçbir yere yazmaz ve bir hafta sonra kimse ne vaat edildiğini ne de kime edildiğini hatırlar.

Nasıl çalışır

Arama, geri kaynağa bağlantılı iz olarak zamanlanmış bir rutin üzerinden board’a girer. Bir döngü onu uygun müşteri dosyasıyla bağlar ve sorumlu ile son tarih içeren bir görev önerir. Öneri, öneri olarak kalır: veritabanındaki gate, bir agent’ın onu kapatmasına izin vermez ve onu kapatacak yazım, bunu kimin istediğini belirtmek zorundadır.

Rezultatul

Görev, ortaya çıktığı bağlam ekli olarak görünür; böylece aramada olmayan bir iş arkadaşı, konuşmayı yeniden kurmadan ne yapılması gerektiğini anlayabilir. Bir kişi sorumluyu, son tarihi ve ifadeyi onaylar — ya da öneriyi reddeder, ki bu da aynı derecede bilgilendiricidir.

Ce este necesar:Sursa trebuie conectată efectiv, cu acces autorizat, și trebuie să existe un acord al echipei asupra a ce înseamnă o sarcină atribuită. Sistemul nu presupune consimțământul nimănui.

İş birliği olanakları

Taskin, kuruluşunuzun bağlamında.

İç akışlar ve bilgi

Yetkilendirilmiş kaynakların bağlanması, bilginin düzenlenmesi ve işlemlerin ekip tarafından, rollere göre ayrı erişimle gözden geçirilmesi.

Özel şirketler

Gerçek bir süreç etrafında bir pilot tanımlıyoruz: kullanıcılar, veriler, entegrasyonlar, maliyetler ve kabul kriterleri. Sonucun değerlendirilmesinden sonra genişleme gelir.

Kamu kurumları ve şirketleri

Erişilebilirlik, barındırma, veri koruması ve birlikte çalışabilirlik gereksinimlerini belirliyoruz. AGE veya STISC hizmetleriyle herhangi bir bağlantı, uygunluk, erişim ve onayların doğrulanmasını gerektirir.

Bunlar uyarlama senaryolarıdır, mevcut sözleşmeler veya ortaklıklar hakkında beyanlar değildir. Önerilen işlevler projenin çalışma alanında doğrulanır.

Bir pilotu konuşalım

Bir ekosistemin parçası.

Konuşmalar ve destek

aichat

İşletmenizin bilgisine bağlı, müşterilerinizin size yazdığı kanallarda çalışan bir asistan.

Platformă

Bilgi ve koordinasyon

Cronberry

Cronberry yetkili kaynakları, konuşmaları ve ilişkileri tek bir araştırma ve koordinasyon alanında toplar.

Geliştirme ve gösterimler

Sohbet biçimli formlar

Megaforms

Megaforms, sesli yanıt ve transkripsiyon dâhil, sohbet biçimli formlarla yanıt toplamayı araştırır.

Geliştirme ve gösterimler

Neyin daha iyi çalışmasını isterdiniz?

Bize sürecinizi anlatın. Neyin kurulmaya değer olduğuna, neyi bağlayabileceğimize ve sonucu nasıl doğrulayacağımıza birlikte karar verelim.

Hadi konuşalım