Operatör Yüzeyleri

Kurulum, paper run, runtime izleme, review ve troubleshooting için hangi yüzeyin kullanılacağı.

Hangi yüzeyi ne zaman kullanmalısın?

Agentic Trader'da birden fazla operatör yüzeyi var, çünkü farklı işler farklı detay seviyesi ister.

Yüzey	En iyi kullanım	Doğrulanacak şey
Argümansız launcher	Web GUI, paper daemon, Ink, Rich, setup veya model-service yolunu seçmek	herhangi bir şeyi başlatmadan önce seçenekleri açıklıyor mu?
CLI komutları	kurulum, JSON kontrol, tek seferlik paper run, evidence capture	komut çıktısı, exit code, persist edilmiş kayıtlar
Rich menü	terminal navigasyonu ve hızlı status review	CLI JSON ile aynı backend/runtime gerçeği
Ink control room	canlı lokal izleme, settings, recent runs, operator instructions	resize davranışı, current runtime mode, latest activity
observer API	Web GUI attach akışları ve makine-okunur status	dashboard, status, supervisor, broker, research payload'ları
Web GUI	browser tabanlı command center ve review panelleri	route-boundary validation, section error'ları, dashboard parity
docs sitesi	ürün rehberi, özellik açıklamaları ve katkı sınırları	docs runtime ile uyumlu mu, istenen gelecek hâli mi anlatıyor

Shared truth kuralı

Hiçbir yüzey kendine ait özel bir runtime modeli üretmemeli. Bir ekran runtime, broker, memory, review ya da health state gösteriyorsa bu shared contract'lerden gelmelidir.

Tüm ekranlar aynı account, broker backend, runtime mode, son karar, readiness gate'leri ve degraded state'ler üzerinde anlaşmalı. Anlaşmazlarsa önce alt katman runtime ve persistence kanıtına güven.

Yaygın operatör görevleri

Sistemin hazır olup olmadığını kontrol et

Şunları kullan:

agentic-trader setup-status --json
agentic-trader model-service status --json
agentic-trader webgui-service status --json
agentic-trader provider-diagnostics --json
agentic-trader v1-readiness --json
agentic-trader broker-status --json
agentic-trader finance-ops --json
agentic-trader supervisor-status --json
agentic-trader proposal-candidates --json
agentic-trader trade-proposals --json

Bu komutlar provider evidence, model readiness, broker mode, account/PnL/exposure evidence, runtime state ve daemon sağlığının devam etmek için yeterince görünür olup olmadığını gösterir.

Bir trade fikrini execute edilebilir hâle gelmeden incele

Scanner veya research çıktısı doğrudan order olmamalı; önce broker-free proposal candidate olmalı. proposal-candidate-create adayı persist eder, proposal-candidates scanner/research evidence'ını gösterir ve proposal-candidate-promote kontrol edilmiş adayı pending manual-review proposal'a dönüştürür. proposal-create yalnızca manuel paper-desk fikirleri içindir; trade-proposals pending ve terminal kararları gösterir, proposal-approve veya proposal-reject ise açık insan review adımıdır. Onay hâlâ yapılandırılan paper veya external-paper broker adapter'ından geçer ve execution intent/outcome audit trail'i bırakır.

External-paper broker accepted acknowledgement'ları fill sayılmaz; in-flight kalır ve proposal-refresh orijinal broker order'ını okuyup fill, partial-fill, cancel veya reject durumunu kanıtlayana kadar yeniden order göndermez.

Web GUI Proposal Desk aynı kuyruğu okur ve yalnızca explicit approve, reject, reconcile veya refresh kontratlarını çağırabilir. Generic broker console değildir ve proposal kuyruğu dışında order oluşturmaz.

Paper cycle çalıştır veya incele

İlk strict run için CLI kullan, sonra CLI JSON, Rich/Ink, Web GUI panelleri ve evidence bundle üzerinden incele. Broker/account veya execution truth önemliyse tek bir UI kartına güvenme.

Background service sorununu çöz

supervisor-status --json, observer /supervisor ve son log tail'lerini kullan. Blocked gate, dead PID, stale heartbeat state ve stop request durumları generic "not running" mesajının arkasına saklanmamalı.

İlk yüzeyi seç

Ürün launcher'ı için agentic-trader komutunu argümansız çalıştır. Bu yüzey setup, Web GUI, model-service ve daemon hazır oluşunu gösterir, sonra hangi yüzeyi açacağını sorar. Trading daemon'ı sessizce başlatmamalıdır. Özellikle Ink control room istiyorsan agentic-trader tui kullan.

Web GUI'nin yapmasına izin verilenler

API sınırında web input'unu doğrulamak
mevcut runtime sözleşmelerine delegasyon yapmak
operatöre dönük copy ve kontroller sunmak
shared status'u güvenli biçimde poll ya da refresh etmek

Web GUI'nin yapmaması gerekenler

paralel bir orkestrasyon yolu yaratmak
web-only execution semantiği üretmek
optimistic UI arkasında safety gate saklamak
gevşek bir chat yolu üzerinden operator intent'i mutate etmek

Docs'e özel yüzey kuralı

Docs uygulaması da bir yüzeydir. Görevi runtime'ı ve ürün workflow'larını açıklamaktır; ikinci bir runtime hikâyesi yazmak değil.

Bunun anlamı:

feedback copy; verinin lokal log'a mı, GitHub'a mı, yoksa ikisine birden mi gittiğini açıkça söylemeli
docs sayfaları neyin shipped, gated, scaffold veya future scope olduğunu açıkça göstermeli
ürün memory'si, review evidence'ı ve katkı veren .ai notları dilde ayrışmalı

Yüzey işi için değişiklik kontrol listesi

önce backend contract'i doğrula
UI'nin doğru alanları okuduğunu doğrula
degrade state'lerin görünür kaldığını doğrula
davranış değiştiyse en az bir operator-facing QA turu çalıştır

On this page