AI ഉപയോഗിച്ച് നിർമ്മിച്ച ആപ്പ് എങ്ങനെ ഡീബഗ് ചെയ്യാം: ഒരു പ്രായോഗിക രീതി

AI ഉപയോഗിച്ച് നിർമ്മിച്ച ആപ്പ് ഡീബഗ് ചെയ്യാൻ, ആദ്യം പ്രശ്നം ബോധപൂർവ്വം വീണ്ടും ഉണ്ടാക്കുക, പിന്നെ തെളിവുകൾ ശേഖരിക്കുക — കൃത്യമായ ഘട്ടങ്ങൾ, പിശക് സന്ദേശം, ബ്രൗസർ കൺസോളും network ടാബും കാണിക്കുന്നത് — എന്നിട്ട് അത് “ഞാൻ X ചെയ്തു, Y പ്രതീക്ഷിച്ചു, Z കിട്ടി” എന്ന രീതിയിൽ AI-ക്ക് നൽകുക. ഒരു പരിഹാരം കാര്യങ്ങൾ വഷളാക്കുന്നെങ്കിൽ, അതിന് മുകളിൽ കൂടുതൽ പരിഹാരങ്ങൾ അടുക്കുന്നതിന് പകരം അവസാനം പ്രവർത്തിച്ച പതിപ്പിലേക്ക് റോൾബാക്ക് ചെയ്യുക. ഇതൊന്നും ചെയ്യാൻ കോഡ് വായിക്കേണ്ടതില്ല.

ഈ ഗൈഡ് മുഴുവൻ ലൂപ്പും ഉൾക്കൊള്ളുന്നു, ഡെവലപ്പർ അല്ലാത്തവർക്കായി ബ്രൗസർ devtools-ന്റെ ഒരു ചെറിയ പരിചയവും.

ഡീബഗ്ഗിംഗ് ലൂപ്പ്

ഓരോ ബഗ് പരിഹാരവും, ഒരു മനുഷ്യൻ ചെയ്താലും AI ചെയ്താലും, ഒരേ ലൂപ്പ് പിന്തുടരുന്നു:

1. വീണ്ടും ഉണ്ടാക്കുക — ബഗ് വിശ്വസനീയമായി സംഭവിപ്പിക്കുക.
2. നിരീക്ഷിക്കുക — പിശക് സന്ദേശവും ആപ്പ് എന്ത് ചെയ്യുകയായിരുന്നു എന്നതും ശേഖരിക്കുക.
3. വിവരിക്കുക — AI-ക്ക് കൃത്യമായ ഘട്ടങ്ങളും പ്രതീക്ഷിച്ച ഫലവും യഥാർത്ഥ ഫലവും നൽകുക.
4. പരിഹരിക്കുക — ഒരു കാര്യം മാത്രം മാറ്റാൻ AI-യെ അനുവദിക്കുക.
5. പരിശോധിക്കുക — അതേ ഘട്ടങ്ങൾ ആവർത്തിച്ച് അത് ശരിയായെന്നും സമീപത്തുള്ളതൊന്നും തകർന്നില്ലെന്നും ഉറപ്പാക്കുക.
6. ആവശ്യമെങ്കിൽ റോൾബാക്ക് ചെയ്യുക — കാര്യങ്ങൾ മോശമായെങ്കിൽ, പഴയ പതിപ്പിലേക്ക് മടങ്ങി മികച്ച വിവരങ്ങളോടെ വീണ്ടും ശ്രമിക്കുക.

AI-നിർമ്മിത ആപ്പുകളിൽ പാഴാകുന്ന സമയത്തിന്റെ വലിയ പങ്കും വരുന്നത് 1, 2, 5 ഘട്ടങ്ങൾ ഒഴിവാക്കുന്നതിൽ നിന്നാണ്: “അത് തകർന്നിരിക്കുന്നു” എന്ന് മാത്രം പറയുക, പരീക്ഷിക്കാതെ ഒരു മാറ്റം അംഗീകരിക്കുക, എന്നിട്ട് തകർന്നതിന് മുകളിൽ മറ്റൊരു പരിഹാരം ചോദിക്കുക.

ഘട്ടം 1: ബഗ് വീണ്ടും ഉണ്ടാക്കുക

ആവശ്യപ്പെടുമ്പോൾ ഉണ്ടാക്കാൻ കഴിയുന്ന ബഗ് പകുതി പരിഹരിച്ചത് പോലെയാണ്. അത് ഉണ്ടാക്കുന്ന ഏറ്റവും ചെറിയ ഘട്ടങ്ങൾ കണ്ടെത്താൻ ശ്രമിക്കുക.

സ്വയം ചോദിക്കുക:

• എല്ലായ്പ്പോഴും സംഭവിക്കുന്നുണ്ടോ? ചിലപ്പോൾ മാത്രമാണെങ്കിൽ, സംഭവിക്കുമ്പോൾ എന്താണ് വ്യത്യസ്തം — ഒരു പ്രത്യേക റെക്കോർഡ്, മന്ദഗതിയിലുള്ള കണക്ഷൻ, ലോഗൗട്ട് ആയിരിക്കൽ?
• എല്ലാ ഉപയോക്താക്കൾക്കും സംഭവിക്കുന്നുണ്ടോ? മറ്റൊരു അക്കൗണ്ടിൽ ലോഗിൻ ചെയ്യുക. പല ബഗുകളും ഡാറ്റയില്ലാത്ത പുതിയ ഉപയോക്താക്കൾക്കോ വ്യത്യസ്ത റോളുള്ള ഉപയോക്താവിനോ മാത്രമാണ് കാണിക്കുന്നത്.
• എല്ലാ ഉപകരണങ്ങളിലും സംഭവിക്കുന്നുണ്ടോ? ഫോൺ വീതിയിലുള്ള സ്ക്രീനും മറ്റൊരു ബ്രൗസറും പരീക്ഷിക്കുക.
• ഒരു പ്രത്യേക മാറ്റത്തിന് ശേഷം തുടങ്ങിയോ? ഇന്നലെ പ്രവർത്തിച്ചിരുന്നെങ്കിൽ, അവസാനത്തെ കുറച്ച് മാറ്റങ്ങളാണ് പ്രധാന സംശയിതർ.

ഘട്ടങ്ങൾ ഒരു ചെറിയ നമ്പർ ലിസ്റ്റായി എഴുതുക. പിന്നീട് പ്രോംപ്റ്റിൽ ഇത് ഒട്ടിക്കും.

ഘട്ടം 2: പിശക് സന്ദേശം വായിക്കുക

പിശക് സന്ദേശങ്ങൾ ഭയപ്പെടുത്തുന്നതായി തോന്നാം, പക്ഷേ അതിലെ കുറച്ച് ഭാഗങ്ങൾ മാത്രം മതി.

ഇത് മനസ്സിലാക്കേണ്ടതില്ല; കൃത്യമായി പകർത്തണം. “Cannot read properties of undefined (reading 'name')” എന്നത് കോഡ് ഒരു ഡാറ്റ (ഒരുപക്ഷേ ബുക്കിംഗോ ഉപയോക്താവോ) പ്രതീക്ഷിച്ചിരുന്നു, അത് എത്തിയില്ല എന്ന് AI-യോട് പറയുന്നു. “some undefined error” എന്ന പാരാഫ്രേസ് ആ വിവരം നഷ്ടപ്പെടുത്തുന്നു.

ചില സാധാരണ പിശകുകളുടെ ഏകദേശ അർത്ഥം:

• undefined / null പിശകുകൾ — കോഡ് പ്രതീക്ഷിച്ച ഡാറ്റ എത്തിയില്ല. പലപ്പോഴും ലോഡിംഗ് അവസ്ഥയോ കോഡ് കൈകാര്യം ചെയ്യാത്ത ശൂന്യമായ ലിസ്റ്റോ ആണ് കാരണം.
• 404 Not Found — പേജോ API വിലാസമോ നിലവിലില്ല. പലപ്പോഴും റൂട്ടിലെ അക്ഷരത്തെറ്റോ പേര് മാറ്റിയ പേജിലേക്കുള്ള ലിങ്കോ.
• 401 Unauthorized / 403 Forbidden — request ലോഗിൻ ചെയ്തിരുന്നില്ല, അല്ലെങ്കിൽ ഉപയോക്താവിന് ആ പ്രവൃത്തി ചെയ്യാൻ അനുമതിയില്ല.
• 500 Internal Server Error — സെർവർ-സൈഡ് കോഡ് തകർന്നു. യഥാർത്ഥ കാരണം ബ്രൗസറിലല്ല, സെർവർ ലോഗുകളിലാണ്.
• CORS പിശകുകൾ — വേറൊരു ഡൊമെയ്‌നിലേക്കുള്ള request ബ്രൗസർ തടഞ്ഞു. സാധാരണയായി സെർവർ കോൺഫിഗറേഷൻ പ്രശ്നമാണ്.

ഘട്ടം 3: ബ്രൗസർ ഡെവലപ്പർ ടൂളുകൾ ഉപയോഗിക്കുക

എല്ലാ ഡെസ്ക്ടോപ്പ് ബ്രൗസറുകളിലും അന്തർനിർമ്മിത ഡെവലപ്പർ ടൂളുകൾ (“devtools”) ഉണ്ട്. അവ പേജ് പിന്നണിയിൽ എന്ത് ചെയ്യുന്നു എന്ന് കാണിക്കുന്നു. Chrome, Edge, Firefox എന്നിവയിൽ പേജിൽ എവിടെയെങ്കിലും വലത് ക്ലിക്ക് ചെയ്ത് Inspect തിരഞ്ഞെടുക്കുക, അല്ലെങ്കിൽ F12 അമർത്തുക (Mac-ൽ Cmd+Option+I). Safari-യിൽ ആദ്യം Safari-യുടെ settings-ൽ Develop മെനു ഓൺ ചെയ്യുക.

മൂന്ന് ടാബുകൾ മാത്രം മതി.

Console

Console ടാബ് പേജിന്റെ കോഡിൽ നിന്നുള്ള പിശകുകളും സന്ദേശങ്ങളും കാണിക്കുന്നു. പിശകുകൾ ചുവപ്പിലാണ്. ഒരു ബട്ടൺ ക്ലിക്ക് ചെയ്താൽ ഒന്നും സംഭവിക്കുന്നില്ലെങ്കിൽ, ക്ലിക്ക് ചെയ്യുന്ന നിമിഷത്തിൽ കൺസോളിൽ പലപ്പോഴും ഒരു ചുവന്ന പിശക് കാണാം. പിശകിന്റെ മുഴുവൻ വാചകം പകർത്തുക (മിക്ക ബ്രൗസറുകളിലും അതിൽ വലത് ക്ലിക്ക് ചെയ്താൽ copy ഓപ്ഷൻ ഉണ്ട്).

Network

Network ടാബ് പേജ് ഉണ്ടാക്കുന്ന എല്ലാ request-കളും കാണിക്കുന്നു — ഡാറ്റ ലോഡ് ചെയ്യുന്നത്, ഒരു ഫോം സേവ് ചെയ്യുന്നത്, ലോഗിൻ ചെയ്യുന്നത്. അത് തുറക്കുക, തുടർന്ന് ബഗിന് കാരണമാകുന്ന ഘട്ടങ്ങൾ ആവർത്തിക്കുക.

• ചുവപ്പ് വരികൾ അല്ലെങ്കിൽ 400-നോ അതിന് മുകളിലോ സ്റ്റാറ്റസുള്ള വരികൾ നോക്കുക.
• പരാജയപ്പെട്ട വരിയിൽ ക്ലിക്ക് ചെയ്ത് അതിന്റെ Response കാണുക. സെർവർ പിശക് പലപ്പോഴും സ്ക്രീനിലുള്ളതിനെക്കാൾ ഉപയോഗപ്രദമായ ഒരു സന്ദേശം അവിടെ നൽകുന്നു.
• Request-ന്റെ URL-ഉം സ്റ്റാറ്റസ് കോഡും ശ്രദ്ധിക്കുക — “/api/bookings-ലേക്കുള്ള POST 500 നൽകി” എന്നത് AI-ക്ക് നൽകാൻ വളരെ ഉപയോഗപ്രദമായ ഒരു വാക്യമാണ്.

ബഗിൽ പേജ് റീലോഡോ റീഡയറക്ടോ ഉൾപ്പെടുന്നെങ്കിൽ Preserve log ടിക് ചെയ്യുക, അങ്ങനെ request-കൾ അപ്രത്യക്ഷമാകില്ല.

Elements

Elements (അല്ലെങ്കിൽ Inspector) ടാബ് പേജിന്റെ ഘടനയും സ്റ്റൈലുകളും കാണിക്കുന്നു. ലേഔട്ട് ബഗുകൾക്കാണ് ഇത് ഏറ്റവും ഉപയോഗപ്രദം: ഒരു ഘടകത്തിന് മുകളിൽ ഹോവർ ചെയ്താൽ അതിന്റെ വലിപ്പവും ഇടവും ഹൈലൈറ്റ് ആകും. ഇവിടെ ഒന്നും എഡിറ്റ് ചെയ്യേണ്ടതില്ല; “ഫൂട്ടർ ഫോണിൽ 2,000 പിക്സൽ വീതിയിലാണ്, പേജിനെ വശത്തേക്ക് തള്ളുന്നു” എന്ന് പറഞ്ഞാൽ മതി.

ഘട്ടം 4: സെർവർ ലോഗുകൾ പരിശോധിക്കുക

ചില ബഗുകൾ സെർവറിലാണ് സംഭവിക്കുന്നത്, ബ്രൗസറിന് അത് കാണാനാകില്ല. Network ടാബിലെ 500 പിശക് ഇതിന്റെ ക്ലാസിക് സൂചനയാണ്. സെർവർ ലോഗുകൾ — നിങ്ങളുടെ ബാക്കെൻഡ് പ്രവർത്തിക്കുമ്പോഴുള്ള ടെക്സ്റ്റ് ഔട്ട്പുട്ട് — സാധാരണയായി യഥാർത്ഥ പിശക് stack trace (പരാജയപ്പെടുമ്പോൾ പ്രവർത്തിച്ചിരുന്ന ഫംഗ്ഷനുകളുടെ പട്ടിക) സഹിതം അടങ്ങിയിരിക്കും.

അവ എവിടെ കാണാമെന്നത് നിങ്ങളുടെ ടൂളിനെ ആശ്രയിച്ചിരിക്കുന്നു. മിക്ക AI ആപ്പ് ബിൽഡറുകളിലും പ്രോജക്റ്റിനായി ഒരു terminal അല്ലെങ്കിൽ log വ്യൂ തുറക്കാം, അല്ലെങ്കിൽ AI-യോട് ലളിതമായി ചോദിക്കാം: “അവസാന request-ലെ പിശകുകൾക്കായി സെർവർ ലോഗുകൾ പരിശോധിച്ച് എന്താണ് പരാജയപ്പെട്ടതെന്ന് പറയൂ.”

ഘട്ടം 5: AI-യോട് ബഗ് വിവരിക്കുക

നിങ്ങൾ ശേഖരിച്ചത് ഈ രൂപത്തിൽ വെക്കുക:

ബുക്കിംഗ്സ് പേജിൽ, ഒരു അംഗമായി ലോഗിൻ ചെയ്ത്: നാളത്തെ 9:00 ക്ലാസിൽ Cancel ക്ലിക്ക് ചെയ്തു. പ്രതീക്ഷിച്ചത്: ബുക്കിംഗ് അപ്രത്യക്ഷമാകുകയും ക്ലാസിൽ ഒരു സ്ഥലം കൂടുതൽ ഒഴിവാകുകയും ചെയ്യണം. യഥാർത്ഥത്തിൽ: സ്ക്രീനിൽ ഒന്നും മാറുന്നില്ല. കൺസോളിൽ BookingCard.tsx:31-ൽ TypeError: Cannot read properties of undefined (reading 'id') കാണുന്നു, network ടാബിൽ DELETE /api/bookings/123 500 നൽകി. കാരണം കണ്ടെത്തി പരിഹരിക്കുക, ഒരു അംഗത്തിന് ഒരു ബുക്കിംഗ് ഉള്ളപ്പോഴും പല ബുക്കിംഗ് ഉള്ളപ്പോഴും cancel പ്രവർത്തിക്കുന്നുണ്ടെന്ന് പരിശോധിക്കുക.

ഓരോ ഭാഗവും പ്രധാനമായ കാരണം:

• എവിടെ, ആരായി എന്നത് ഒരു സ്ക്രീനിലേക്കും ഒരു റോളിലേക്കും ചുരുക്കുന്നു.
• കൃത്യമായ ഘട്ടങ്ങൾ AI-ക്ക് പ്രശ്നം വീണ്ടും ഉണ്ടാക്കാൻ അനുവദിക്കുന്നു.
• പ്രതീക്ഷിച്ചതും യഥാർത്ഥവും “പരിഹരിച്ചു” എന്നതിന്റെ അർത്ഥം നിർവചിക്കുന്നു.
• പിശക് വാചകവും പരാജയപ്പെട്ട request-ഉം കാരണത്തിലേക്ക് നേരിട്ട് ചൂണ്ടുന്നു.
• “പരിശോധിക്കുക…” എന്നത് AI-യോട് എഡിറ്റ് മാത്രമല്ല, ഉറപ്പാക്കാനും ആവശ്യപ്പെടുന്നു.

AI രണ്ട് തവണ പരിഹരിക്കാൻ ശ്രമിച്ച് പരാജയപ്പെട്ടാൽ, ഒന്നും മാറ്റുന്നതിന് മുമ്പ് വിശദീകരിക്കാൻ ആവശ്യപ്പെടുക:

ഇപ്പോൾ കോഡ് മാറ്റരുത്. ഇതിന് കാരണം എന്താണെന്ന് നിങ്ങൾ കരുതുന്നു, അതിനെ പിന്തുണയ്ക്കുന്ന തെളിവ് എന്താണ്?

തെറ്റായ ഒരു സിദ്ധാന്തം എഴുതിവെക്കുമ്പോൾ എളുപ്പത്തിൽ തിരിച്ചറിയാം, തെറ്റായ ഒരു പരിഹാരത്തെക്കാൾ തിരുത്താൻ വളരെ ചെലവ് കുറവുമാണ്.

ഘട്ടം 6: പരിശോധിക്കുക, ചുറ്റുമുള്ളതും നോക്കുക

AI പരിഹരിച്ചെന്ന് പറയുമ്പോൾ, ഘട്ടം 1-ലെ അതേ ഘട്ടങ്ങൾ ആവർത്തിക്കുക. പിന്നെ അതിന് ചുറ്റുമുള്ളവ പരിശോധിക്കുക:

• വ്യത്യസ്ത ഉപയോക്തൃ റോളിന് അതേ പ്രവൃത്തി
• ഡാറ്റയില്ലാതെയും ധാരാളം ഡാറ്റയുള്ളപ്പോഴും അതേ പ്രവൃത്തി
• നിങ്ങൾ പരിഹരിച്ച ഘടകം പങ്കിടുന്ന പേജുകൾ
• ലേഔട്ട് മാറ്റിയിരുന്നെങ്കിൽ ഫോൺ വീതിയിലുള്ള സ്ക്രീൻ

AI മാറ്റങ്ങൾ ചിലപ്പോൾ ഒരു വഴി ശരിയാക്കുകയും മറ്റൊന്ന് നിശബ്ദമായി തകർക്കുകയും ചെയ്യാറുണ്ട്. ഇപ്പോൾ രണ്ട് മിനിറ്റ് പരിശോധിക്കുന്നത് പിന്നീടുള്ള ഒരു മണിക്കൂർ ആശയക്കുഴപ്പം ഒഴിവാക്കും.

ഘട്ടം 7: അടുക്കുന്നതിന് പകരം റോൾബാക്ക് ചെയ്യുക

ഒരു പരിഹാരം കാര്യങ്ങൾ മോശമാക്കിയാലോ, മൂന്ന് റൗണ്ട് പുരോഗതിയില്ലാതെ പോയാലോ, തിരികെ പോകുക. മൂന്ന് തെറ്റായ പരിഹാരങ്ങൾക്ക് മുകളിൽ നാലാമത്തെ പരിഹാരം ചോദിക്കുന്നതിനെക്കാൾ, അവസാനം പ്രവർത്തിച്ച പതിപ്പിലേക്ക് റോൾബാക്ക് ചെയ്ത് മികച്ച തെളിവുകളോടെ വീണ്ടും പറയുന്നതാണ് എപ്പോഴും മികച്ചത്. പരാജയപ്പെടുന്ന ഓരോ ശ്രമവും കോഡ് അവശേഷിപ്പിക്കുന്നു, ആ കോഡ് അടുത്ത ശ്രമത്തെ ആശയക്കുഴപ്പത്തിലാക്കുന്നു.

റോൾബാക്ക് എളുപ്പമാക്കുന്ന നല്ല ശീലങ്ങൾ:

• ഓരോ മാറ്റത്തിന് ശേഷവും പരീക്ഷിക്കുക, ഏത് മാറ്റമാണ് തകർത്തതെന്ന് അറിയാൻ.
• മാറ്റങ്ങൾ ചെറുതാക്കുക — ഒരു സന്ദേശത്തിൽ ഒരു ഫീച്ചർ അല്ലെങ്കിൽ ഒരു പരിഹാരം മാത്രം.
• അപകടകരമായ എന്തെങ്കിലും തുടങ്ങുന്നതിന് മുമ്പ് അവസാനം പ്രവർത്തിച്ച പതിപ്പ് രേഖപ്പെടുത്തുക.
• കോഡ് Git-ലാണെങ്കിൽ, പ്രവർത്തിക്കുന്ന പതിപ്പുകൾ commit ചെയ്യുക, അവയിലേക്ക് മടങ്ങാൻ.

AI-നിർമ്മിത ആപ്പുകളിലെ സാധാരണ ബഗ് രീതികൾ

ഇത് ബഗ് അല്ലാത്തപ്പോൾ

ചില “ബഗുകൾ” AI-യോട് പറഞ്ഞത് കൃത്യമായി നിർമ്മിച്ചതും വിവരണം അവ്യക്തമായിരുന്നതുമാണ്. നിങ്ങൾ ആവശ്യപ്പെടുന്ന പരിഹാരം യഥാർത്ഥത്തിൽ പെരുമാറ്റത്തിലെ മാറ്റമാണെങ്കിൽ അത് വ്യക്തമായി പറയുക: “ഇത് ഇങ്ങനെയാക്കുക…”. ശരിയായ പെരുമാറ്റം എന്താണെന്ന് തന്നെ അറിയില്ലെങ്കിൽ, ആദ്യം അത് തീരുമാനിക്കുക. നിയമങ്ങൾ വ്യക്തമായി വ്യക്തമാക്കുന്നതിനെക്കുറിച്ച് AI ആപ്പ് ബിൽഡറുകൾക്കുള്ള പ്രോംപ്റ്റുകൾ എഴുതുന്നത് എങ്ങനെ വിശദീകരിക്കുന്നു. യഥാർത്ഥ ഉപയോക്താക്കൾക്കായി ഒരു ആപ്പ് തയ്യാറാക്കുകയാണെങ്കിൽ, ഒരു AI പ്രോട്ടോടൈപ്പ് പ്രൊഡക്ഷനിലേക്ക് കൊണ്ടുപോകുന്നത് എങ്ങനെ ലോഞ്ചിന് മുമ്പ് ചെയ്യേണ്ട പരിശോധനകൾ വിശദീകരിക്കുന്നു.

Mythex-ൽ ഡീബഗ്ഗിംഗ്

ലൂപ്പിന്റെ ഓരോ ഘട്ടത്തിനും Mythex-ൽ ഉപകരണങ്ങളുണ്ട്:

• Preview ബഗ് വീണ്ടും ഉണ്ടാക്കാൻ, ഫോൺ വലുപ്പത്തിലുള്ള ഫ്രെയിം ഉൾപ്പെടെ.
• /test ഏജന്റ് നിങ്ങളുടെ ലൈവ് പ്രിവ്യൂവിൽ ഒരു ഉപയോക്താവിനെപ്പോലെ ക്ലിക്ക് ചെയ്ത് തകർന്ന ഫ്ലോകൾ റിപ്പോർട്ട് ചെയ്യുന്നു.
• /fix തകർച്ചയിലേക്ക് ഏജന്റിനെ പ്രത്യേകമായി ചൂണ്ടുന്നു.
• Plan മോഡ് ഏജന്റിന് എന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് അന്വേഷിച്ച് വിശദീകരിക്കാൻ അനുവദിക്കുന്നു.
• Code → terminal നിങ്ങളുടെ ആപ്പിന്റെ സെർവർ ലോഗുകൾ കാണിക്കുന്നു.
• ഏതെങ്കിലും മറുപടിയിലെ Revert to this point ആ മറുപടിയിലെ ചെക്ക്പോയിന്റിലേക്ക് പ്രോജക്റ്റ് റോൾബാക്ക് ചെയ്യുന്നു.

പ്രസിദ്ധീകരണം പരാജയപ്പെട്ടാൽ, പബ്ലിഷ് ഡയലോഗ് സാധാരണയായി Fix with AI നൽകുന്നു, അത് build ഔട്ട്പുട്ടോ ആപ്പിന്റെ ലോഗുകളോ വായിക്കുന്നു. ഡോക്സിൽ Debug your app, Publish troubleshooting എന്നിവ കാണുക.

ചോദ്യങ്ങൾ