Claude Code Desktop-dan istifadə

Terminal Claude Code-un doğma mühitidir, amma yeganə mühiti deyil. Claude Desktop tətbiqinin içindəki Claude Code eyni agent-i qrafik interfeyslə verir: session-lar yan paneldə, dəyişikliklər diff kimi, icazə sorğuları düymə ilə, bir neçə layihə eyni anda. Bu fəsil Desktop-u iki məqsədlə istifadə edir. Birincisi, paralel session-ların idarəsini göstərmək: eyni spec-dən iki ayrı implementasiya. İkincisi, uzun müddətli yaddaşın, yəni iyerarxik CLAUDE.md fayllarının və memory/ qovluğunun, və browser üzərindən test-in praktikada necə işlədiyini göstərmək.

Terminal, Desktop, IDE, web

Claude Code-un dörd səthi var və hamısı eyni harness-i işlədir:

Səth	Nə verir	Nə vaxt
Terminal	Tam nəzarət, skript, SSH, headless	Gündəlik iş, avtomatlaşdırma
Desktop tətbiqi	Session siyahısı, diff görünüşü, paralel layihələr, icazə düymələri	Bir neçə session-ı eyni anda izləmək
IDE genişlənməsi	Editor-da diff, seçilmiş kod context kimi, inline review	Kod oxuyub redaktə edərkən
Web	Cloud mühitində session, repository-ni clone edən sandbox	Lokal maşından asılı olmayan iş, mobil

Seçim üstünlük məsələsidir, amma bir qayda var: konfiqurasiya hamısında eynidir. CLAUDE.md, settings, hook-lar, MCP server-lər, skill-lər, hamısı repository-dən və istifadəçi qovluğundan oxunur. Desktop-a keçəndə heç nəyi yenidən qurmursunuz. Fərq yalnız interfeysdədir: Desktop-da hər session ayrı pəncərədir, agent-in hər dəyişikliyi faylın diff-i kimi görünür, icazə sorğuları terminal mətni yox, düymədir, və bir session işləyərkən digərinə keçmək klik məsafəsindədir.

Bu sonuncu xüsusiyyət Desktop-un əsas dəyəridir. Terminalda üç paralel session üç terminal pəncərəsi və hansının nə etdiyini yadda saxlamaq deməkdir. Desktop-da hər session-ın vəziyyəti, yəni işləyir, təsdiq gözləyir, bitib, siyahıda görünür.

Nümunə: eyni spec, iki implementasiya

6-cı fəsildə paralel session-lar üçün git worktree-ni gördük. Desktop bu işi asanlaşdırır: eyni repository-ni iki ayrı qovluqda, iki ayrı session-da açırsınız və hər ikisinə eyni spec-i verirsiniz. relnotes üçün spec memory/spec/CLAUDE.md faylındadır: data modeli, səhifələr, axtarış, test tələbləri. Hər session-a eyni cümlə gedir: "spec-ə uyğun tam implementasiya yaz".

Nəticə 2-ci fəslin probabilistik generasiya dərsini canlı göstərir. Birinci implementasiya data-nı bir faylda saxlayıb siyahını server tərəfdə render edir; ikinci implementasiya eyni data modeli ilə client tərəfdə filtr qurur. Hər ikisi spec-i qarşılayır, hər ikisində test-lər keçir, amma kodun strukturu, komponentlərin bölgüsü, hətta adlandırma fərqlidir.

Bunun praktik faydası iki yerdədir. Birincisi, spec-in yoxlanması: iki implementasiyanın ayrıldığı yer spec-in natamam olduğu yerdir. Axtarışın diakritiklərə həssaslığı bir implementasiyada var, digərində yoxdursa, spec bunu deməyib. İkincisi, seçim: iki variantdan yaxşısını götürmək və ya birinin data qatını digərinin UI qatı ilə birləşdirmək olur. Desktop-da iki session-ı yan-yana görmək bu müqayisəni mümkün edir.

İyerarxik CLAUDE.md

relnotes layihəsinin yaddaşı bir faylda deyil, iyerarxiyadadır:

relnotes/
├── CLAUDE.md                 # command-lar, architecture, test strategiyası
├── memory/
│   ├── spec/CLAUDE.md        # tam məhsul spec-i
│   ├── frontend/CLAUDE.md    # UI qərarları: komponent bölgüsü, stil qaydaları
│   └── screenshots/          # browser test-lərinin şəkilləri
└── src/
    └── api/CLAUDE.md         # API qovluğunun öz qaydaları

Kök CLAUDE.md qısadır: npm run dev, npm run build, npm test kimi command-lar, üç cümləlik architecture, test strategiyası və bir istiqamət: "məhsul tələbləri memory/spec/-də, UI qərarları memory/frontend/-dədir; lazım olanda oxu". src/api/CLAUDE.md yalnız agent API qovluğunda işləyəndə yüklənir. memory/ altındakı fayllar isə avtomatik yüklənmir; agent onları istinadla, yəni lazım olanda, oxuyur.

Bu bölgünün məntiqi birinci fəsildəndir: hər session-da lazım olan şey kökdə, bəzən lazım olan şey memory/-də, yalnız bir qovluqda lazım olan şey həmin qovluqda. Context xərci işə görə dəyişir: UI tapşırığında memory/frontend/ oxunur, API tapşırığında yox.

`memory/` qovluğu: uzunmüddətli yaddaş

memory/ qovluğunun ikinci rolu yazmaqdır. Agent iş bitirəndə qəbul etdiyi qərarları geri yazır: "kart komponenti üçün HookCard adı seçildi, prop-ları tipli Hook obyektidir; tarix formatı ISO, göstərilən format lokal". Növbəti session, hətta /clear-dən və ya tamam başqa gündən sonra, bu faylı oxuyur və eyni qərarlarla davam edir. Kök CLAUDE.md-dəki bir sətir bunu avtomatlaşdırır: "Dizayn qərarı verəndə onu memory/frontend/CLAUDE.md-yə əlavə et".

Bu, agent-in context window-undan kənarda yaddaşıdır və 11-ci fəsildəki deep agent-lərin file system sütununun əl ilə qurulmuş formasıdır. İki qayda onu işlək saxlayır. Birincisi, yaddaş faylları da redaktə olunmalıdır: köhnəlmiş qərar yanlış göstərişdir. İkincisi, fayllar bir-birini təkrarlamamalıdır: spec bir yerdə, qərarlar bir yerdə, kök CLAUDE.md yalnız yol göstərir.

Browser ilə test: Playwright MCP

UI implementasiyasının spec-ə uyğunluğunu yoxlamağın ən etibarlı yolu ona baxmaqdır. Playwright MCP server-i agent-ə browser verir: səhifəni açır, elementləri tapır, klik edir, screenshot çəkir. 4-cü fəsildəki kimi qoşulur:

claude mcp add playwright -- npx @playwright/mcp@latest

Sonra tapşırıq belə olur: "Dev server-i işə sal, ana səhifəni aç, axtarışa 'auth' yaz, nəticə siyahısının screenshot-unu memory/screenshots/search-auth.png kimi saxla və spec-dəki tələblərlə müqayisə et". Agent səhifəni real browser-də görür, elementlərin olub-olmadığını yoxlayır, və screenshot-u fayla yazır. Screenshot-ların memory/ altında saxlanmasının səbəbi var: onlar sonrakı session-larda referans olur, "əvvəlki vəziyyət belə idi, indi belədir" müqayisəsi mümkün olur.

Browser test-i agent loop-unu bağlayır. 2-ci fəsildə dedik ki, agent yalnız ölçə bildiyi şeyi düzəldə bilir; unit test məntiqi ölçür, browser isə görünüşü. Agent "düymə sağdadır" iddiasını screenshot ilə yoxlayanda, siz ona inanmaq məcburiyyətində qalmırsınız.

Desktop-da bu iş axını xüsusilə rahatdır: iki implementasiya üçün iki session, hər birində Playwright ilə eyni ssenari, screenshot-lar yan-yana. Spec-in hansı implementasiyada daha yaxşı qarşılandığı bir baxışla görünür.

Desktop-da review və icazə

Desktop-un terminaldan ən çox fərqləndiyi yer dəyişikliklərin review-udur. Terminalda agent-in Edit-i mətn kimi axır; Desktop-da hər dəyişiklik fayl üzrə diff görünüşündə dayanır və siz onu commit-dən əvvəl oxuyursunuz. Bu, agent-in işini PR kimi review etməyin ən yaxın formasıdır: hansı fayllar dəyişib, hər faylda nə əlavə olunub, nə silinib. Review vərdişi burada da eynidir: agent-in izahını yox, diff-i oxuyun.

İcazə sorğuları da düymə kimi gəlir və bir neçə session paralel işləyəndə bu, vacib olur: hansı session nəyə icazə istəyir, siyahıda görünür və siz bir-bir cavab verirsiniz. Qayda dəyişmir: "həmişə icazə ver" seçimi settings faylına yazılır və sonrakı session-larda, terminalda da, qüvvədədir. Desktop-da verilən icazə terminalda verilən icazədən fərqlənmir, çünki ikisi də eyni konfiqurasiyanı oxuyur.

Web səthi bir addım da irəli gedir: session sizin maşınınızda yox, cloud mühitində işləyir, repository oraya clone olunur və nəticə branch kimi qayıdır. Bu, uzun tapşırığı başladıb kompüteri bağlamağa, telefondan vəziyyətə baxmağa imkan verir. Qiymət mühitin fərqidir: lokal maşındakı alətlər, environment dəyişənləri və daxili şəbəkə orada yoxdur; CLAUDE.md-də "test-lər üçün lokal database lazımdır" kimi fərziyyələr cloud session-da işləmir. Hansı səthdə işlədiyinizdən asılı olmayaraq, layihənin mühit tələblərini açıq yazmaq həmişə faydalıdır.

Session-ların idarəsi

Desktop ilə bir neçə session işlədəndə bir neçə vərdiş faydalıdır:

Hər session-a bir məqsəd. Session-ın adı və ilk prompt-u məqsədi deməlidir; paralel session-lar bir-birinin işinə girməməlidir.
Worktree ilə izolyasiya. Eyni qovluqda iki session eyni faylı dəyişə bilər; ayrı worktree bunun qarşısını alır.
Təsdiq növbəsi. Bir neçə session eyni anda icazə gözləyəndə Desktop-un vəziyyət göstəricisi hansının gözlədiyini deyir; uzun tapşırıqları avtomatik qəbul rejimində, riskli olanları default rejimdə işlədin.
Nəticəni yaddaşa yazdırın. Session bitəndə qərarlar memory/-yə, yarımçıq işlər isə plan faylına yazılsın; növbəti session oradan başlayır.

Terminal, Desktop, IDE və web arasında seçim sizin üslubunuzdur; konfiqurasiya və prinsiplər dəyişmir. Dəyişən yalnız neçə agent-i eyni anda rahat idarə edə bilməyinizdir.

Tapşırıqlar

Kiçik bir feature üçün spec yazıb onu iki ayrı worktree-də iki session-a verin. Nəticələri müqayisə edin və ayrıldıqları hər nöqtəni spec-də natamam bənd kimi qeyd edin. Spec-i düzəldib üçüncü session-da təkrar edin: variasiya azaldımı?
Layihənizin yaddaşını iyerarxiyaya bölün: kök CLAUDE.md, memory/ altında spec və qərarlar, bir alt qovluq CLAUDE.md. Hər səviyyənin yükləndiyi anı /context ilə müşahidə edin.
Playwright MCP qoşun və UI-nin bir ssenarisini agent-ə test etdirin: səhifə aç, hərəkət et, screenshot saxla, spec ilə müqayisə et. Agent-in iddia etdiyi ilə screenshot-da gördüyünüz üst-üstə düşdümü?