Lokal debug: loglar, MCP‑inspeksiya və Dev Mode

1. Niyə lokal debug üçün ayrıca mühazirə

Ötən modullarda artıq Apps SDK və MCP stekinin necə qurulduğunu araşdırmışdıq. İndi isə danışaq: niyə ümumiyyətlə lokal debug haqqında ayrıca mühazirə lazımdır.

Çoxlarında yol belədir: «Sadəcə ChatGPT‑ni açacağam, "mənim App‑ımı istifadə et" yazacağam, sonra da nə deyəcəyinə baxacağam. İşləməsə — kodu təsadüfi şəkildə dəyişəcəyəm». Bu, yalnız brauzerdəki HTML səhifəsinə baxaraq backend düzəltməyə və server loglarına heç bir dəfə də baxmamağa bənzəyir.

ChatGPT Apps ilə «sehrə» sürüşmək xüsusilə asandır: GPT var, aləti çağırıb‑çağırmamağa özü qərar verir, öz xəta məntiqi var. Kapotun altında nə baş verdiyini görmürsünüzsə, debug «şaman ayini»nə çevrilir.

Məqsədimiz: bunu normal mühəndis prosesinə çevirmək:

• Next/MCP loglarına haradan baxmağı bilirsiniz;
• MCP serveri inspektor vasitəsilə əllə çağırmağı bacarırsınız;
• Dev Mode‑un nəyi yoxladığını anlayırsınız və ChatGPT‑nin ümumiyyətlə serverinizə çata bildiyinə necə əmin olmağı bilirsiniz.

Və ən önəmlisi: «GPT təxmin oyunu» ilə sazlamaqdan imtina edib əvvəlcə steykin aşağı səviyyələrini — server və protokolu — yoxlayırsınız, sonra isə UI və modelin davranışını.

2. Zehni model: debug üçün üç səviyyə

Xaosa qərq olmamaq üçün debugu üç səviyyə terminləri ilə düşünməyi razılaşaq. Bu bizim kiçik «laylı piroq»umuzdur:

İkinci səviyyədə bizi MCP serverin özü (alətlər, DB, API) maraqlandırır, üçüncüdə isə artıq «naqillər» və MCP mesaj formatı (JSON‑RPC, sxemlər və s.).

Bu üçlük — mühazirənin və debug kursunun planının əsasını təşkil edir.

Aydınlıq üçün sorğunun axınına baxa bilərik:

sequenceDiagram
    participant User as Istifadəçi
    participant ChatGPT as ChatGPT (Dev Mode)
    participant Tunnel as Tunel (ngrok/CF)
    participant Next as Next.js + MCP

    User->>ChatGPT: "$50-dək hədiyyə seç"
    ChatGPT->>Next: tools/call search_gifts (Tunel vasitəsilə)
    Next->>Next: MCP alətini çağırırıq, DB/API-yə gedirik
    Next-->>ChatGPT: JSON-RPC nəticə + ToolOutput
    ChatGPT-->>User: Cavab + vidcet renderi

İstənilən nöqtədə sıradan çıxa bilər: tunel, endpoint, MCP məntiqi, JSON sxemi, React vidceti. Debug zamanı sizin vəzifəniz — xətranın məhz hansı təbəqədə olduğunu anlamaq, yoxsa hər şeyi ard‑arda yenidən yazmaq deyil.

3. Next.js və MCP logları: hər şeyin əsası

Ən darıxdırıcı və ən faydalı şeydən başlayaq — loqlardan.

Lokal inkişaf zamanı loglar haradadır

Next.js üzərində Apps SDK‑nın standart şablonunda MCP server, adətən, API marşrutuna bükülür (/api/mcp və ya oxşarı). Siz npm run dev işə salırsınız və bir terminalda:

• Next.js dev serveri;
• JSON‑RPC sorğularını (tools/list, tools/call və s.) qəbul edən MCP endpoint işləyicisi;
• console.log/console.error vasitəsilə bütün hadisələrin çıxışı.

Əgər MCP‑ni ayrıca prosesə çıxarmısınızsa, orada ikinci terminal olacaq, amma ideya eynidir: maraqlı hər şey konsolda görünür.

Fərqləndirmək vacibdir:

• yığma/başlatma xətaları — next dev qalxmır, TypeScript yıxılır, səhv import və s.;
• icra xətaları — hər şey başladı, amma konkret /api/mcp sorğusu alətin yıxılmasına gətirir.

Next.js dev rejimində runtime xətalarını həm də gözəl overlay ilə göstərir, üstəlik stack trace‑i konsola yazır.

MCP serverində nəyi loqlamalı

MCP JSON‑RPC protokolundan istifadə etsə də, debug üçün bütün JSON‑u tam çap etmək lazım deyil. Daha faydalısı qısa, amma strukturlaşdırılmış loglardır.

MCP loqları üçün yaxşı praktika — ən azı aşağıdakıları loqlamaqdır: timestamp, request_id/traceId, alətin adı, parametrlər (anonimləşdirilmiş), status (ok/error) və icra vaxtı.

GiftGenius üçün ən sadə logger.ts bu cür görünə bilər:

// src/lib/logger.ts
export function logToolEvent(
  phase: "start" | "end" | "error",
  data: Record<string, unknown>
) {
  const ts = new Date().toISOString();
  console.log(JSON.stringify({ ts, phase, ...data }));
}

Və alətin işləyicisində:

// src/mcp/tools/searchGifts.ts
import { logToolEvent } from "@/lib/logger";

export async function searchGiftsTool(args: { q: string }) {
  const traceId = crypto.randomUUID();

  logToolEvent("start", { tool: "search_gifts", traceId, args });

  try {
    // ... hədiyyə axtarışının real hissəsi ...
    const results = []; // müvəqqəti stub

    logToolEvent("end", { tool: "search_gifts", traceId, count: results.length });

    return results;
  } catch (err) {
    logToolEvent("error", { tool: "search_gifts", traceId, error: String(err) });
    throw err;
  }
}

İki vacib incəlik var.

Birincisi, loglarda tam e‑mail, telefon, kart nömrələri, tokenlər saxlamayın. Bu, təkcə düzgün deyil, həm də MCP təhlükəsizlik praktikasına ziddir.

İkincisi, traceId — ən yaxşı dostunuzdur. Next.js və MCP loqlarını birlikdə baxanda hadisələri onunla asanlıqla əlaqələndirirsiniz: konkret tools/call sorğusu, uyğun React render və vidcet şəbəkə loqu.

Loglara görə harada yıxıldığını necə anlamaq

Terminalınız var, orada logToolEventdən JSON sətirlər uçur. Tipik ssenari:

• phase: "start" və tool: "search_gifts" gəldi;
• phase: "end" yoxdur, əvəzində phase: "error" və stack trace var;
• bundan görünür ki, alət sizin məntiqinizə qədər çatıb, amma içəridə nəyisə sındırıb — məsələn, xarici API sorğusu, parsinq, DB ilə iş.

Əgər ümumiyyətlə bu alət adı üçün loqları görmürsünüzsə — deməli, sorğu alətə qədər çatmayıb. Onda steykin yuxarılarına qalxırsınız: tunel, /mcp endpoint, tools/call JSON sorğusu.

4. MCP Inspector: MCP‑ni ChatGPT‑dən əvvəl sazlamaq

Əgər loglar — sizin gözlərinizdirsə, MCP Inspector (və ya MCPJam Inspector) — mikroskopdur.

MCP Inspector haqqında daha ətraflı və nə üçün lazımdır

MCP modulunda artıq «Hello, MCP» serverini yoxlamaq üçün Inspectoru qoşmuşduq. Burada onu əsas debug aləti kimi istifadə edirik: əvvəlcə MCP‑nin öz‑özünə canlı olduğuna əmin oluruq, sonra isə Dev Mode və UI‑a baxırıq.

Inspector — ayrıca tətbiqdir (çox vaxt veb‑UI üstəgəl CLI), MCP müştərisi rolunu oynayır. O, serverinizə HTTP/SSE və ya stdin/stdout ilə qoşulur, tools/list, tools/call icra edir və xam JSON mesajları, handshake, alət siyahısı, resurslar və s. göstərir.

Baş ideya: ChatGPT‑ni tənlikdən çıxarmaq. Əgər alətiniz işləmir, əvvəlcə serverin canlı olub‑olmadığını, protokol və sxemin düzgünlüyünü anlamaq istəyirsiniz — GPT‑ni günahlandırmazdan əvvəl.

Inspector ilə mini iş axını

Tipik lokal debug ssenarisi belə görünür:

1. Next.js + MCP endpoint qalxsın deyə npm run dev işə salırsınız.
2. MCP Inspectoru işə salırsınız, məsələn:

npx @modelcontextprotocol/inspector

(dəqiq əmrlər istifadə olunan alətdən asılıdır).

3. Inspector‑da MCP endpoint URL‑inizi göstərirsiniz, məsələn http://localhost:3000/api/mcp (və ya onu da yoxlamaq istəyirsinizsə HTTPS tuneli).
4. Handshake keçib‑keçmədiyinə baxırsınız: server dəstəklənən capabilities, alətlərin siyahısı, resurslar və s. ilə cavab verməlidir.
5. Aləti əllə çağırırsınız: search_gifts seçirsiniz, arqumentləri daxil edirsiniz {"q": "30‑a qədər qız üçün"}, «Call tool» düyməsini basırsınız və baxırsınız:
   • cavab gəlibmi;
   • JSON‑RPC və ya MCP xətası qayıdıb‑qayıtmayıb;
   • bu çağırış üçün server loglarda nə yazır.

Əgər artıq Inspector‑da hər şey yıxılırsa, ChatGPT‑ni belə açmağa ehtiyac yoxdur: MCP serverini düzəldin.

Inspector‑da hər şey əladırsa, amma ChatGPT yenə də şikayət edirsə — deməli problem yuxarıdadır: Dev Mode URL, autorizasiya, modelin davranışı.

“Qəsdən aləti sındırdıq” nümunəsi

Gəlin bizim search_gifts alətini qəsdən sındıraq:

export async function searchGiftsTool(args: { q: string }) {
  if (args.q === "sındır") {
    throw new Error("Debug nümayişi üçün tədris xətası");
  }
  // ... normal məntiq ...
  return [];
}

Daha sonra:

1. Inspector‑da search_gifts alətini {"q": "sındır"} arqumenti ilə çağırırsınız.
2. Loqlarda phase: "error" və stack trace görürsünüz.
3. MCP serverinin xətanı dürüst qaytardığına əmin olursunuz.

Sonra bunu ChatGPT Dev Mode‑a qoşduğunuzda və modeldən «"sındır" sözü ilə hədiyyə seç» istədiyinizdə, o aləti çağırmağa cəhd edəcək və istifadəçiyə «I encountered an error running the tool» kimi mesaj göstərəcək. Görünür: xəta modelə görə deyil, sizin atdığınız istisnaya görə çıxır.

Bu fənd düşüncə tərzini yaxşı məşq etdirir: siz biznes xətasını (özümüz Error atdıq) protokol xətasından (JSON‑u sındırdıq, alətin adı yanlışdır və s.) aydın ayırırsınız.

5. Vidcet debugu: DevTools, state və «debug banner»

MCP serveri təxmini aydın olduqda, frontenda — Apps SDK vidcetinə keçiririk.

Vidcet xətalarına harada və necə baxmalı

Vidcetiniz ChatGPT daxilində iframe qum qutusunda render olunur. Amma yaxşı xəbər: bu iframe üçün də eyni brauzer DevTools‑u var.

Mini prosedur:

1. ChatGPT‑ni brauzerdə açın (Chrome/Edge/Firefox).
2. DevTools‑u açın (adətən F12 və ya Ctrl+Shift+I).
3. Console sekmesi — vidcetinizin yaşadığı freym kontekstini seçin (tez‑tez bu domen web-sandbox.oaiusercontent.com olur).
4. Çatı yeniləyin/mesaj göndərin ki, GPT sizin App‑i göstərsin.

Əgər vidcet:

• heç görünmədisa;
• boz/boş göründüsə;
• konsolda qırmızı xəta göstərirsə

— bu, demək olar ki, React kodu problemidir: əlçatmaz property, səhv import, nasaz hook və s.

Network sekmesi də faydalıdır. Orada görəcəksiniz:

• tətbiqinizin JS bundle‑ının yüklənməsini (əgər 404/500 — problem dev server/tunel tərəfindədir);
• vidcetinizin window.fetch vasitəsilə kənara etdiyi sorğuları və 4xx/5xx cavabları.

Ən sadə debug banner

Çox əlverişli üsul — vidcetinizin kök komponentinə kiçik «debug banner» əlavə etməkdir; Dev Mode‑da bu, mühitin nə olduğunu və build versiyasını göstərir.

Məsələn:

// src/components/DebugBanner.tsx
export function DebugBanner() {
  if (process.env.NODE_ENV !== "development") return null;

  return (
    <div style={{ padding: 4, background: "#222", color: "#0f0", fontSize: 10 }}>
      ENV: dev | build: local | {new Date().toLocaleTimeString()}
    </div>
  );
}

Və vidcetin kök komponentində:

// src/app/widget/page.tsx
import { DebugBanner } from "@/components/DebugBanner";

export default function GiftGeniusWidget() {
  return (
    <div>
      <DebugBanner />
      {/* hədiyyə axtarışı üçün qalan UI */}
    </div>
  );
}

Əgər ChatGPT‑ni açdınız, App‑i işə saldınız, amma banneri görmədiniz — deməli, JS ümumiyyətlə brauzerə çatmayıb: ya yığma xəta var, ya endpoint problemi, ya da vidcet sadəcə MCP serverində qeydiyyatdan keçməyib.

Lokal state və xəta emalı

Vidcetiniz artıq müxtəlif hallar göstərməyi bacarmalıdır: yüklənir, uğur, xəta. Əgər yoxdursa — tam vaxtıdır əlavə etməyin.

Mini pattern:

const [status, setStatus] = useState<"idle"|"loading"|"error"|"success">("idle");

async function handleSearch(query: string) {
  try {
    setStatus("loading");
    // MCP alətini window.openai.callTool və ya Apps SDK hook-u ilə çağırırıq
    setStatus("success");
  } catch (e) {
    console.error("Search failed", e);
    setStatus("error");
  }
}

JSX‑də:

{status === "error" && (
  <div style={{ color: "red" }}>Nəsə düzgün getmədi, yenidən cəhd edin.</div>
)}

Debug üçün vacibdir ki:

• istisnaları udmayasınız (yoxsa konsol boş olacaq, UI isə sadəcə «asılı» qalacaq);
• xətanı UI‑da açıq göstərəsiniz, yoxsa istifadəçiyə elə gələcək ki, App öldü.

6. Debugun bir hissəsi kimi Dev Mode: nə edir və səbəbsiz günahlandırmamaq

İndi şəkilə ChatGPT Dev Mode‑u da daxil edək. Buna qədər yalnız sizin kodu nəzərdən keçirdik. Amma bəzən hər şey lokala işləyir, Inspector əla göstərir, ancaq ChatGPT yenə «Error talking to [AppName]» yazır və ya ümumiyyətlə sizin App‑i təklif etmir.

Dev Mode nə edir

Dev Mode — ChatGPT‑də bir rejimdir, burada siz:

• öz App‑larınızı yarada və redaktə edə bilərsiniz;
• MCP serverin endpointini göstərirsiniz (adətən https://sizin-domen/mcp və ya /api/mcp);
• Store‑a dərc etmədən manifest və metadataları tez yeniləyə bilirsiniz.

Debug baxımından Dev Mode sadəcə daha bir konfiqurasiya təbəqəsidir:

• orada səhv URL göstərilibsə;
• axırda /mcp əlavə etməyi unutmusanızsa;
• tunel yeni domen veribsə, amma siz ayarları yeniləməmisinizsə

— ChatGPT sadəcə serverinizə çata bilmir.

Dev Mode‑un tipik sınıq ssenarisi

Janr klassikası:

1. https://abcd.ngrok.io tunelini qaldırdınız, onu Dev Mode‑da göstərdiniz, hər şey işləyirdi.
2. Ertəsi gün ngrok‑u yenidən başlatdınız, https://efgh.ngrok.io aldınız.
3. Dev Mode‑da hələ də https://abcd.ngrok.io/mcp yazılıb.
4. ChatGPT «Error talking to GiftGenius» yazır.

Bu zaman MCP Inspector, http://localhost:3000/api/mcp ünvanına yönləndirilmiş, hər şeyin qaydasında olduğunu göstərir. Bu o deməkdir ki, MCP canlıdır, amma ChatGPT başqa yerə baxır.

Həll: Dev Mode ayarlarına daxil olun, URL‑i yeniləyin, sondakı /mcp‑ni unutmayın.

Dev Mode vs Store

Bu mühazirədə yalnız Dev Mode haqqında danışırıq — bu, sizin qum qutunuzdur. Burada URL‑i tez‑tez dəyişmək, tuneli yenidən qoşmaq, alət sxemlərini düzəltmək normaldır.

Sonra Store‑a gedəndə, endpoint daha sərt sabitləşəcək və belə fokuslar yaxşı fikir olmayacaq. Amma Store‑a hələ bir neçə modul var, ona görə hələlik sakitcə Dev Mode‑da sındırıb düzəldirik.

7. Mini debug alqoritmi: «heç nə işləmir» olanda nə etməli

İndi hər şeyi praktik alqoritmdə toplayaq. Mahiyyətcə bu, mühazirənin əvvəlindəki üç debug səviyyəsidir, sadəcə addım‑addım yazılıb.

Tutaq ki, ChatGPT‑ni açdınız, GiftGenius seçdiniz, «Dost‑geek üçün $30‑dək hədiyyə seç» yazdınız və:

• GPT App haqqında heç nə yazmır;
• və ya «Error talking to GiftGenius» yazır;
• və ya boş/boz vidcet açılır.

Necə ümidsizliyə düşməməli?

Addım 1 (MCP/server səviyyəsi). MCP‑ni Inspector və loglarla yoxlayın

Əvvəlcə GPT və UI‑ı kənara qoyuruq. Yalnız server maraqlıdır.

1. npm run dev işlədiyinə və endpointin (/api/mcp) cavab verdiyinə əmin olun.
2. MCP Inspectoru http://localhost:3000/api/mcp və ya tunelinizə qoşun.
3. Handshake‑i yoxlayın — alətlərin siyahısı görünməlidir.
4. GPT‑nin çağırmalı olduğu eyni aləti (məsələn, search_gifts) oxşar arqumentlərlə əllə çağırın.

Əgər burada artıq hər şey yıxılırsa — MCP‑ni düzəldin: sxemlər, biznes məntiq, şəbəkə çağırışları. Nəyin sındığını anlamaq üçün loglardan və traceId‑dən istifadə edin.

Addım 2 (protokol/Dev Mode səviyyəsi). Dev Mode və URL‑i yoxlayın

Inspector‑da hər şey əladırsa, amma ChatGPT hələ də sizin App‑i görmür və ya bağlantı problemləri yazırsa:

1. App‑iniz üçün Dev Mode ayarlarını açın.
2. Orada MCP üçün hansı URL göstərildiyinə baxın.
3. Onu serverinizin/tunelinizin həqiqətən dinlədiyi ünvanla tutuşdurun (və serveriniz tələb edirsə, sonda /mcp olduğuna əmin olun).

Çox vaxt problem məhz buradadır.

Addım 3 (UI səviyyəsi). Vidceti DevTools ilə yoxlayın

Əgər ChatGPT alətləri uğurla çağırırsa (MCP loqlarından görünür), amma vidcet qəribə davranırsa:

1. ChatGPT səhifəsində brauzerin DevTools‑unu açın.
2. Console sekməsi — vidcetinizin iframe kontekstini seçin.
3. JS xətalarına baxın.
4. Network sekməsi — əmin olun ki:
   • vidcetin JS bundle‑ı 404/500 olmadan yüklənir;
   • əlavə sorğular (fetch/window.openai.fetch vasitəsilə) məntiqli cavablar qaytarır.

Paralel olaraq DebugBanner‑ə baxın: əgər o görünmürsə, deməli, ümumiyyətlə React ağacına çatmamısınız.

Addım 4. Bug reportu yenidən yaratmaq üçün Dev Mode‑dan istifadə

Həmkarınızdan/istifadəçidən bug report aldıqda, xətanın baş verdiyi dəqiq promptu saxlamağa çalışın. Dev Mode ssenarini çox tez təkrarlamağa imkan verir:

1. npm run dev işə salın, tuneli qaldırın.
2. Dev Mode‑da App seçin.
3. Problemli promptu yerləşdirin.
4. Paralel olaraq:
   • loglarda MCP‑yə gələn JSON sorğularına baxın;
   • lazım gələrsə, Inspector‑da eyni arqumentlərlə tools/call təkrarlayın.

Beləliklə, «bəzən nəsə işləmir» problemini təkrarlana bilən ssenariyə çevirirsiniz.

8. Rahat debug üçün kiçik kod əlavələri

Mövzunu möhkəmlətmək üçün GiftGenius tətbiqimizə daha bir neçə faydalı fraqment əlavə edək.

Mühit konfiqurasiyası və loglama səviyyələri

Server konfiqurasiyasında MCP endpointini və loglama səviyyəsini açıq yazmaq rahatdır:

// src/config.ts
export const config = {
  mcpEndpoint:
    process.env.NODE_ENV === "development"
      ? "http://localhost:3000/api/mcp" // tunel bunu örtür
      : "https://api.giftgenius.com/api/mcp",
  logLevel: process.env.NODE_ENV === "development" ? "DEBUG" : "ERROR",
};

Və logToolEvent‑də logLevel‑i nəzərə almaq olar ki, prod‑da artıq spam olmasın.

MCP üçün strukturlaşdırılmış xətaların loqlanması

Alətləri işləyərkən gözlənilən xətaları tutub anlaşılan mesajlar qaytarmağa çalışın, hər şeyi throw etməyin:

export async function searchGiftsTool(args: { q: string }) {
  const traceId = crypto.randomUUID();
  logToolEvent("start", { tool: "search_gifts", traceId, args });

  try {
    // ... normal kod ...
    return { content: [{ type: "text", text: "3 hədiyyə tapıldı" }] };
  } catch (err) {
    logToolEvent("error", { tool: "search_gifts", traceId, error: String(err) });

    return {
      content: [{ type: "text", text: "Hədiyyə axtarışında xəta. Daha sonra yenidən cəhd edin." }],
      isError: true,
    };
  }
}

Belə olduqda ChatGPT nəticənin isError kimi işarələndiyini görəcək və problemi istifadəçiyə düzgün bildirəcək, siz isə nə baş verdiyini loqlarda görəcəksiniz.

9. ChatGPT App üçün lokal debug zamanı tipik səhvlər

Səhv №1: «GPT vasitəsilə» yox, server və inspektor vasitəsilə sazlamamaq.
Sadəcə modelin nə cavab verdiyinə baxmaq və harada bug olduğunu təxmin etməyə çalışmaq çox cazibədardır. Amma model — ən üst təbəqədir. Əgər MCP server öz‑özünə (əllə, Inspector vasitəsilə) işləmir — GPT‑dən möcüzə gözləməyin. Əvvəlcə MCP‑ni sabit işlədin, sonra ChatGPT‑ni qoşun.

Səhv №2: loglara heç baxmamaq və ya hər şeyi ard‑arda loqlamaq.
Logların olmaması tam korluğa aparır: hansı alətin çağırıldığını, hansı arqumentlərlə və nə ilə bitdiyini bilmirsiniz. Həddən artıq log isə konsolu əlaqəsiz sətirlərdən ibarət «matris»ə çevirir. tool, args (anonimləşdirilmiş), traceId, status və icra vaxtı olan yığcam, strukturlaşdırılmış log daha yaxşıdır.

Səhv №3: loglarda həssas məlumat saxlamaq.
Tokenlər, tam e‑mail və kart nömrələrini loqlamaq — həm təhlükəsizlik, həm də OpenAI siyasəti baxımından pis praktikadır. Loqlarda yalnız debuga həqiqətən kömək edən məlumat olmalıdır, şəxsi məlumatları isə maskalayın və ya ümumiyyətlə yazmayın.

Səhv №4: bütün günahlar üçün Dev Mode‑u günah keçisi etmək.
Dev Mode tez‑tez günah keçisinə çevrilir: «OpenAI nəsə sındırıb». Əslində çox vaxt problem ondan ibarətdir ki, tuneli yenidən işə saldıqdan sonra URL‑i yeniləməmisiniz və ya yanlış yol göstərmisiniz (/ əvəzinə /mcp). Dəstəyə yazmazdan əvvəl, Dev Mode ayarlarına baxın və endpointi serverin faktiki ünvanı ilə tutuşdurun.

Səhv №5: DevTools‑u və vidcet xətasını görməməzdən gəlmək.
Boş və ya boz vidcet demək olar ki, həmişə müştəri tərəfində JavaScript xətası deməkdir. Əgər yalnız MCP loglarına baxır, amma ChatGPT‑də DevTools‑u açmırsınızsa, mənzərənin yalnız yarısını görürsünüz. Avtomatik olaraq F12 basmaq və Console/Network‑a baxmaq vərdişi sizə saatlarla vaxt qazandıracaq.

Səhv №6: «sehrli gecikmələrlə» bug düzəltməyə çalışmaq.
Bəzən setTimeout və ya Thread.sleep‑tipli gecikmə etmək istəyirsiniz ki, «hər şey yüklənsin». MCP/Next/React dünyasında bu demək olar ki, həmişə səhv müalicədir: problem adətən sxemdə, yanlış endpointdə və ya kod xətasındadır, «server çatmadı»da deyil. (Inspector → Dev Mode → vidcet) zəncirində harada qırılma olduğunu anlamaq, onu gecikmələrlə basdırmaqdan yaxşıdır.

Səhv №7: lokalda hər şey işləmədən Vercel‑ə dərc etmək.
«Tez prod‑a çıxaq» istəyi başadüşüləndir, amma sındırılmış MCP‑ni Vercel‑ə daşımaq iki səviyyəli problem əldə etməyin ideal yoludur: lokal və production. Bu modulda məqsədli olaraq tələb edirik: əvvəl MCP Jam/Inspector → hər şey normal, Dev Mode → baza ssenariləri işləyir və yalnız sonra dərc.