​
Communications V1 Blueprint

​
Goal

Ilk iterasyonun hedefi, Communications domain’ini calisir hale getirmek ve sistemi tek bir gercek signal ile dogrulamaktir. Bu ilk signal:
  • wordpress_plugin_not_connected
Bu signal sunu ifade eder:
  • kullanicinin WordPress tabanli bir sitesi var
  • fakat Watchman Tower WordPress plugin baglantisi yok
Bu durumda kullaniciya tek bir recommendation email’i gonderilebilir.

​
V1 Promise

V1 sonunda sistem su is akisini desteklemeli:
  1. Ergene uygun kullanicilari degerlendirir
  2. wordpress_plugin_not_connected sinyalini uretir
  3. aktif kural ile mesaji esler
  4. gonderim politikasini kontrol eder
  5. email gonderimini tetikler
  6. delivery kaydi olusturur
Bu surumde tek bir signal, tek bir mesaj ve tek bir kural ile baslanir.

​
V1 Boundaries

​
Included

  • email channel
  • tek signal
  • tek recommendation message
  • tek active rule
  • manual run veya cron tabanli evaluator
  • delivery log
  • send-once policy

​
Excluded

  • coklu signal yonetimi
  • visual builder
  • multi-step journeys
  • A/B testing
  • analytics depth beyond delivery status
  • message branching

​
First Signal

​
Signal Key

  • wordpress_plugin_not_connected

​
Signal Inputs

Bu signal yeni bir veritabani objesi olmak zorunda degil. Ilk iterasyonda hesaplanan bir durum olarak uretilebilir. Gerekli ham veriler:
  • kullanicinin site listesi
  • sitenin WordPress olduguna dair bilgi
  • plugin baglantisinin aktif olup olmadigi

​
Signal Logic

Bir kullanici su durumda sinyale sahiptir:
  • en az bir WordPress sitesi vardir
  • en az bir WordPress sitesi plugin ile bagli degildir

​
Signal Output Shape

Ergene icinde evaluator ciktisi su sekilde sade olabilir: 
type CommunicationSignalResult = {
  key: "wordpress_plugin_not_connected";
  userId: string;
  siteId: string;
  context: {
    siteName?: string;
    domain?: string;
  };
};

​
First Message

​
Message Key

  • wp-plugin-connection-recommendation

​
Category

  • recommendation

​
Channel

  • email

​
Content Intent

Mesajin amaci:
  • kullaniciyi korkutmak degil
  • WordPress plugin baglantisinin faydasini anlatmak
  • tek bir net aksiyona yonlendirmek

​
Example Structure

  • subject
  • body intro
  • one recommendation
  • one CTA
Ornek mantik:
  • WordPress kullandiginizi goruyoruz
  • plugin baglantisi ile daha hizli entegrasyon saglanabilir
  • baglantiyi tamamlamak icin su adimi izleyin

​
First Rule

​
Rule Key

  • wp-plugin-connection-rule

​
Rule Definition

Bu kural su sekilde calisir:
  • signal: wordpress_plugin_not_connected
  • message: wp-plugin-connection-recommendation
  • policy: send once
  • status: active
V1’de tek rule oldugu icin audience ayrica tutulmayabilir. Ancak veri modelinde yerini simdiden acmak mantikli.

​
Proposed Data Model

Ilk iterasyonda asagidaki modeller yeterli olur.

​
CommunicationMessage

type CommunicationMessageCategory =
  | "announcement"
  | "recommendation"
  | "activation"
  | "follow_up";

type CommunicationChannel = "email";
type CommunicationStatus = "draft" | "active" | "archived";

interface CommunicationMessage {
  key: string;
  name: string;
  category: CommunicationMessageCategory;
  channel: CommunicationChannel;
  subjectTemplate: string;
  bodyTemplate: string;
  ctaLabel?: string;
  ctaUrlTemplate?: string;
  status: CommunicationStatus;
  createdAt: Date;
  updatedAt: Date;
}

​
CommunicationRule

type CommunicationTriggerType = "signal";
type CommunicationRuleStatus = "active" | "paused" | "archived";

interface CommunicationRule {
  key: string;
  name: string;
  triggerType: CommunicationTriggerType;
  triggerKey: "wordpress_plugin_not_connected";
  messageId: string;
  policy: {
    sendOnce: boolean;
    cooldownHours?: number;
    maxSendCount?: number;
  };
  status: CommunicationRuleStatus;
  createdAt: Date;
  updatedAt: Date;
}

​
CommunicationDelivery

type CommunicationDeliveryStatus =
  | "queued"
  | "sent"
  | "skipped"
  | "failed";

interface CommunicationDelivery {
  userId: string;
  siteId?: string;
  messageId: string;
  ruleId: string;
  signalKey: string;
  channel: "email";
  status: CommunicationDeliveryStatus;
  reason?: string;
  providerMessageId?: string;
  sentAt?: Date;
  createdAt: Date;
  updatedAt: Date;
}

​
Why No CommunicationAudience Yet

Audience modeli dogru bir abstraction ama V1’de tek signal icin gerekmeyebilir. Bu nedenle V1’de su karar daha saglikli:
  • model seviyesinde CommunicationAudiencei hemen eklememek
  • ama kural tasarimini buna uygun tutmak
Sonraki iterasyonda audience geldigi zaman:
  • broad campaign use-case’leri
  • manual segment gonderimleri
  • feature announcement mesajlari
kolayca eklenebilir.

​
Ergene Runtime Design

V1 icin Ergene tarafindaki akisin sade kalmasi cok onemli.

​
Step 1: Evaluate Signal

Tek bir evaluator gorevi:
  • uygun kullanicilari tara
  • wordpress_plugin_not_connected sonucunu uret
Onerilen servis adi:
  • evaluateWordPressPluginNotConnectedSignal

​
Step 2: Resolve Active Rule

Sistemde bu signal icin aktif rule bulunur. Onerilen servis adi:
  • resolveCommunicationRuleForSignal

​
Step 3: Check Delivery Policy

Daha once ayni kullaniciya ayni rule ile gonderim oldu mu kontrol edilir. Onerilen servis adi:
  • shouldSendCommunication

​
Step 4: Render Message

Mesaj template’i signal context ile birlestirilir. Onerilen servis adi:
  • renderCommunicationMessage

​
Step 5: Send Email

Mevcut email gonderim altyapisina baglanir. Onerilen servis adi:
  • deliverCommunicationEmail

​
Step 6: Write Delivery Log

Sonuc ne olursa olsun kayit acilir:
  • sent
  • skipped
  • failed
Onerilen servis adi:
  • createCommunicationDelivery

​
Suggested Ergene Module Layout

V1 icin Ergene icinde yeni klasor yapisi su olabilir: 
ergene/src/communications/
  index.ts
  runCommunicationSweep.ts
  signals/
    evaluateWordPressPluginNotConnectedSignal.ts
  rules/
    resolveCommunicationRuleForSignal.ts
  policies/
    shouldSendCommunication.ts
  rendering/
    renderCommunicationMessage.ts
  delivery/
    deliverCommunicationEmail.ts
  services/
    createCommunicationDelivery.ts
Bu yapinin amaci:
  • eski generic automation mantigina donmemek
  • amac odakli bir modulle ilerlemek

​
Suggested Shared Models

V1 icin wt-shared/src/models altina su modeller eklenebilir:
  • CommunicationMessage.model.ts
  • CommunicationRule.model.ts
  • CommunicationDelivery.model.ts
Simdilik baska model eklememeyi oneririm.

​
Dashboard V1 Surface

Dashboard bu iterasyonda cok sade olmali.

​
Messages

Yalnizca tek mesaji duzenlemek icin yeterli alanlar:
  • name
  • status
  • subjectTemplate
  • bodyTemplate
  • ctaLabel
  • ctaUrlTemplate

​
Rules

Tek rule icin:
  • active / paused
  • send once
  • cooldown hours
  • max send count

​
Deliveries

Temel tablo:
  • user
  • message
  • signal
  • status
  • sentAt
  • reason
V1’de dashboard uzerinden signal uretilmez. Sadece goruntulenir. Implementasyon sirasi:
  1. wt-shared modellerini ekle
  2. Ergene communications runtime iskeletini kur
  3. wordpress_plugin_not_connected evaluator’unu yaz
  4. tek message seed veya default kaydini tanimla
  5. tek rule ile end-to-end gonderimi calistir
  6. dashboard list/detail ekranlarini ekle

​
Success Criteria

V1 basarili sayilmasi icin:
  • sistem uygun kullaniciyi bulmali
  • gereksiz tekrar gondermemeli
  • tek bir recommendation email gonderebilmeli
  • delivery log kaydi olusmali
  • dashboard uzerinden mesaj ve rule gorulebilmeli

​
Open Questions

Bu blueprint sonrasi netlestirilmesi gerekenler:
  1. WordPress plugin baglantisi hangi veri alanlariyla kesin olarak anlasiliyor?
  2. Bir kullanicinin birden fazla WordPress sitesi varsa tek mesaj mi gidecek?
  3. CTA URL hangi dashboard veya urun sayfasina gitmeli?
  4. Message seed kod ile mi gelecek, dashboard uzerinden mi olusacak?