რეპოზიტორიაში გახსნილმა AI coding ასისტენტმა კოდი იცის და მეტი არაფერი. არ იცის, რომელ პორტზე უსმენს სერვერი, რომ გადატვირთვას მხოლოდ ერთი დირექტორია გადაურჩება, რომ root და systemd არ არსებობს, ან რომ push რამდენიმე წამში ახალ deploy-ს იწვევს. ამიტომ ხვდება: იღებს ტუტორიალების ნაგულისხმევ მნიშვნელობებს - პორტი 3000, localhost, Dockerfile, რომელიც არავის მოუთხოვია, და პაროლი, ჩაწერილი კონფიგურაციის ფაილში. გამოსავალი რეპოზიტორიაში დადებული უბრალო Markdown ფაილია, რომელსაც ასისტენტი მუშაობის დაწყებამდე კითხულობს: CLAUDE.md Claude Code-ისთვის, AGENTS.md Codex-ის, Cursor-ისა და სხვა მზარდი სიის ხელსაწყოებისთვის. GitHub-თან დაკავშირებულ RE:NODE აპლიკაციის სერვერებზე პანელს ამ ფაილის დაწერა შეუძლია შენ მაგივრად: GitHub ჩანართზე ჩართე Keep AI context in the repository და ის გახსნის pull request-ს, რომელიც ამატებს .renode/server.md-ს და მოკლე მონიშნულ ბლოკს CLAUDE.md-სა და AGENTS.md-ში. შენ გადახედავ, merge-ს გააკეთებ, და ამ მომენტიდან ასისტენტმა იცის, როგორ მუშაობს სერვერი, ხელით არავის ჩაუწერია.
ეს პოსტი ორივე ნაწილს ეხება: რა არის context ფაილი და როგორ დაიწერება კარგი ნებისმიერ ჰოსტზე, და ზუსტად რას წერს პანელი, რას არ წერს და როგორ ერთვება მასში pre-flight შემოწმება.
რა არის AI context ფაილი#
context ფაილი ინსტრუქციაა აგენტისთვის და კოდის გვერდით ინახება. როცა აგენტური ხელსაწყო რეპოზიტორიაში სესიას იწყებს, ის ეძებს ცნობილი სახელის ფაილს root-ში (ზოგჯერ ქვედირექტორიებშიც), კითხულობს და მთელი სესიის განმავლობაში მუდმივ ინსტრუქციად აღიქვამს. ეს მკაცრი გაგებით კონფიგურაცია არ არის - არაფერი არ ამუშავებს მას - ეს ტექსტი და სიებია, რომლებსაც მოდელი ისევე კითხულობს, როგორც შენს prompt-ს, იმ განსხვავებით, რომ მას მხოლოდ ერთხელ წერ.
მასში ის ცოდნა ხვდება, რაც ახალ კოლეგას პირველ დღეს დასჭირდებოდა და რაც სხვანაირად უნდა ეკითხა:
- როგორ დაინსტალირდეს, აიგოს, გატესტდეს და გაეშვას პროექტი, ზუსტი ბრძანებებით;
- სად რა დევს და რომელი დირექტორიებია გენერირებული და არ უნდა შეიცვალოს;
- კონვენციები, რომლებიც კოდიდან აშკარა არ არის - სახელდება, შეცდომების დამუშავება, რომელი ბიბლიოთეკა იმარჯვებს, როცა ორივე გამოდგებოდა;
- გარემო, რომელშიც კოდი რეალურად მუშაობს, და მისი ლიმიტები;
- რაც არასოდეს უნდა მოხდეს: საიდუმლოები commit-ში, vendored კოდის რედაქტირება, force push.
ბოლო ორი პუნქტი სწორედ ის ადგილია, სადაც ბევრი context ფაილი ღარიბია და საიდანაც ყველაზე დიდი ზარალი მოდის. ასისტენტი, რომელმაც deploy-ის გარემო არ იცის, კოდს ლეპტოპისთვის წერს. ლეპტოპის კოდი უსმენს 127.0.0.1-ს, ატვირთულ ფაილებს წერს /tmp-ში და თვლის, რომ საჭირო ყველაფრის apt install შეუძლია. კონტეინერულ ჰოსტზე სამივე უხმაუროდ ფუჭდება. აგენტების მიერ სერვერზე მუშაობისას დაშვებულ ზოგად შეცდომებზე ვწერეთ პოსტში AI coding აგენტები სერვერისა და DevOps სამუშაოსთვის; context ფაილი "არასწორი გარემოს" ტიპის შეცდომებისგან ყველაზე იაფი დაცვაა.
რომელი ხელსაწყო რომელ ფაილს კითხულობს#
ერთიანი სტანდარტი ჯერ არ არსებობს და ფაილების სახელები ცოტა არეულია. 2026 წლის ბოლოსთვის სასარგებლო შეჯამება ასეთია:
| ფაილი | ვინ კითხულობს |
|---|---|
CLAUDE.md | Claude Code |
AGENTS.md | OpenAI Codex, Cursor, GitHub Copilot-ის აგენტი და სხვები |
.cursor/rules/ | Cursor (საკუთარი rule ფაილები) |
.github/copilot-instructions.md | GitHub Copilot |
AGENTS.md საერთო ფორმატთან ყველაზე ახლოა: უბრალო Markdown ფაილი სავალდებულო სტრუქტურის გარეშე, რომლის წაკითხვაზეც რამდენიმე მწარმოებელი შეთანხმდა. CLAUDE.md იგივე იდეის Claude Code-ისეული სახელია; ის ქვედირექტორიებში მუშაობისას იქაურ CLAUDE.md ფაილებსაც კითხულობს, ასევე პირადს შენს home დირექტორიაში. ხელსაწყოების მხარდაჭერა სწრაფად იცვლება, ამიტომ თუ ერთ-ერთი მათგანი შენთვის მნიშვნელოვანია, ნახე მისი დოკუმენტაცია, რომელ სახელებს იღებს ამჟამად.
ორი პრაქტიკული დასკვნა. პირველი: თუ შენი გუნდი ერთზე მეტ ასისტენტს იყენებს, ერთი და იგივე ძირითადი ინსტრუქცია ერთზე მეტ ფაილში დაგჭირდება. ხელით მათი იდენტურად შენახვა დიდხანს არ გრძელდება; ჩვეულებრივი გამოსავალი ისაა, რომ საერთო ნაწილი მოკლე იყოს და ორივე ფაილი ერთ უფრო გრძელ დოკუმენტზე მიუთითებდეს. მეორე: ბრაუზერში გახსნილი ჩატ-ასისტენტი, მაგალითად ChatGPT, შენს რეპოზიტორიას თავისით საერთოდ არ კითხულობს. მან მხოლოდ ის იცის, რასაც მას აძლევ - ამიტომ პანელს ამ შემთხვევისთვის share ბმულიც აქვს, რომელზეც ბოლოში ვისაუბრებთ.
რა უნდა ეწეროს და რა არა#
საუკეთესო context ფაილები მოკლეა და კონკრეტული. მოდელი ფაილის ყველა ხაზს ყოველ სესიაზე კითხულობს, ხოლო ზოგადი რჩევებით სავსე გრძელი ფაილი იმ რამდენიმე ხაზს ასუსტებს, რომლებსაც მნიშვნელობა აქვს. სასარგებლო ტესტი თითოეული ხაზისთვის: შეცდებოდა თუ არა ამაში ასისტენტი, რომელსაც ეს ფაილი არასოდეს უნახავს? თუ არა, წაშალე. "დაწერე სუფთა კოდი" ამ ტესტს ვერ აჯერებს. "სერვერი უსმენს SERVER_PORT-ში მითითებულ პორტს და არა 3000-ს" - აჯერებს.
პატარა Node სერვისის ფაილი შეიძლება ასეთი იყოს:
# Orders API## Commands- Install: npm ci- Test: npm test (needs a local Postgres, see docker-compose.yml)- Start: npm start (runs node dist/server.js; build first with npm run build)## Layout- src/ is the code; dist/ is generated - never edit it.- migrations/ is append-only. Add a new file; never change a merged one.## Rules- Read configuration from environment variables only. See .env.example.- Never commit .env or any key, token or password.- Use the existing logger in src/log.ts, not console.log.რა არ უნდა ეწეროს:
- საიდუმლოები. context ფაილი commit-დება, ამიტომ მასში ჩაწერილი ყველაფერი ისტორიაში სამუდამოდ რჩება. დაწერე ცვლადის სახელი, არასოდეს მისი მნიშვნელობა. მნიშვნელობები სად უნდა ინახებოდეს, ამას განიხილავს გარემოს ცვლადები და საიდუმლოები.
- რაც ყოველ deploy-ზე იცვლება. მიმდინარე commit, ბოლო deploy-ის დრო, build-ის ნომერი. ისინი მაშინვე ძველდება და ყველა diff-ს ხმაურიანს ხდის.
- რასაც კოდი თავადაც ამბობს. route-ების სია, ბაზის სქემა. ასისტენტს მათი წაკითხვა შეუძლია; ტექსტში გადაწერა მხოლოდ მეორე ვერსიას ქმნის, რომელიც განსხვავდება.
- გრძელი ტუტორიალები. ბმული მიეცი რეპოზიტორიაში არსებულ დოკუმენტს და ასისტენტი თავად გახსნის, როცა დასჭირდება.
ის ნაწილი, რომელსაც უმეტესობა გამოტოვებს, სერვერია. წერენ ბრძანებებსა და კონვენციებს და ჩერდებიან, რადგან სერვერი სხვისი პრობლემა ჩანს. ეს სწორედ ის ნაწილია, რომლის შევსებაც პანელს შეუძლია, რადგან პანელი ერთადერთი ადგილია, რომელმაც ის ზუსტად იცის.
AI context-ის გადამრთველი GitHub ჩანართზე#
GitHub რეპოზიტორიასთან დაკავშირებულ აპლიკაციის სერვერზე GitHub ჩანართს აქვს გადამრთველი: Keep AI context in the repository (opens a pull request). ის გამორთულია, სანამ არ ჩართავ, და მხოლოდ ამ ერთ კავშირს ეხება. არცერთი რეპოზიტორიისთვის, რომლის მფლობელსაც ეს არ დაუჭერია, არაფერი არასოდეს იხსნება.
როცა ის ჩართულია, პანელის GitHub App - იგივე, რომელიც GitHub-დან deploy-ებს ემსახურება - შემდეგს აკეთებს:
- ქმნის branch-ს სახელით
renode/ai-contextიმ branch-ის თავიდან, საიდანაც შენი სერვერი deploy-დება. - ამ branch-ზე commit-ს უკეთებს
.renode/server.md-ს და მონიშნულ ბლოკებსCLAUDE.md-სა დაAGENTS.md-ში, GitHub-ის API-ით. არაფერი კლონირდება. - ხსნის pull request-ს
renode/ai-context-დან შენს deploy branch-ში. - შენ გადახედავ და merge-ს გააკეთებ ან დახურავ.
პანელი არასოდეს აკეთებს push-ს იმ branch-ზე, საიდანაც შენი სერვერი deploy-დება. ყოველი commit თავის renode/ai-context branch-ზე მიდის, ხოლო merge შენი გადაწყვეტილებაა. renode/ branch-ებზე push-ებს deploy-on-push hook-იც უგულებელყოფს, ამიტომ context-ის განახლება სერვერს არასოდეს რესტარტავს.
გადამრთველის ქვემოთ სტატუსის ხაზი გეუბნება, რა მდგომარეობაა: გამორთულია, მუშაობს, ელოდება ნებართვას, pull request ღიაა შენს branch-ზე, განახლებულია, ბოლო pull request დაიხურა merge-ის გარეშე, ან შეცდომაა. GitHub-ის ყოველი უარი - rate limit, დაცული branch, დაარქივებული რეპოზიტორია, ნებართვის ნაკლებობა - ამ ხაზებიდან ერთ-ერთად გამოჩნდება და არა შეცდომის გვერდად. რეპოზიტორიის დაკავშირების ზოგადი ნაბიჯები deploy-ების გზამკვლევშია.
რას წერს პანელი რეპოზიტორიაში#
ორი სახის შიგთავსი, განსხვავებული მფლობელობით.
ბლოკი CLAUDE.md-სა და AGENTS.md-ში
CLAUDE.md-სა და AGENTS.md-ში პანელს მხოლოდ ორ HTML კომენტარს შორის ტექსტი ეკუთვნის: <!-- renode:start --> და <!-- renode:end -->. თუ ფაილი არ არსებობს, იქმნება და მხოლოდ ბლოკს შეიცავს. თუ არსებობს მარკერების გარეშე, ბლოკი ბოლოში ემატება. თუ მარკერები აქვს, მხოლოდ მათ შორისაა ჩანაცვლებული. რაც მათ გარეთ დაწერე, ბაიტამდე უცვლელი რჩება, ამიტომ შენი ბრძანებები და კონვენციები პანელის ნაწილის ზემოთ ან ქვემოთ დაუმუშავებლად დგას. HTML კომენტარები GitHub-ზე არ რენდერდება, ამიტომ მარკერები უხილავია, როცა ფაილს იქ კითხულობენ.
ბლოკი განზრახ მოკლეა - რამდენიმე წესი, რომელთა უგულებელყოფა deploy-ს არღვევს, და მითითება სრულ ფაილზე. deploy-on-push-ით Node.js სერვერისთვის დაახლოებით ასე გამოიყურება:
<!-- renode:start -->## Renode serverThis repository is deployed to a Renode server (Node.js) from the mainbranch. Read .renode/server.md before changing how it builds, starts orconnects to anything.- Listen on 0.0.0.0 on the port in the SERVER_PORT environment variable. No other port is reachable from outside.- Only /home/container persists. No root, no apt, no systemd, no Docker.- The panel starts it in a fixed order. Keep the entry file and start script it expects.- Never commit secrets. They go in a .env uploaded through the Files tab, or in Startup variables, and are read from the environment.- A push to main redeploys and restarts the server within seconds.- Fix the code, not the startup command or the Docker image.<!-- renode:end -->ზუსტი ტექსტი სერვერზეა დამოკიდებული: runtime-ის სახელზე, branch-ზე, boot ნაბიჯების რაოდენობაზე და იმაზე, ჩართულია თუ არა deploy on push. როცა გამორთულია, push-ის ხაზი ასისტენტს ეუბნება, რომ push-ის შემდეგ სერვერი პანელიდან გადატვირთოს.
სერვერის ფაილი
.renode/server.md მთლიანად პანელს ეკუთვნის, ზევით კომენტარში ამას თავადვე ამბობს და გადაიწერება ყოველ ჯერზე, როცა სერვერის პარამეტრები იცვლება. საკუთარი ჩანაწერები ჩაწერე CLAUDE.md-ში ან AGENTS.md-ში, მარკერების გარეთ, და არა აქ. მას ეს სექციები აქვს:
| სექცია | რას შეიცავს |
|---|---|
| Runtime | სერვერის ტიპი და მისი Docker image |
| Network | პორტი, მისამართი და დომენები (პირად რეპოებში) |
| Code | გზა კონტეინერში, რეპო, branch, deploy გადამრთველები |
| How this server boots | დანომრილი ნაბიჯები, რომლებსაც პანელი გაშვებისას ასრულებს |
| Variables | თითოეული გარემოს ცვლადი, მისი სახელი, საიდუმლოა თუ არა |
| Databases | მიბმული ბაზები (დეტალები მხოლოდ პირად რეპოებში) |
| Limits | მეხსიერება, CPU და დისკი |
| Pre-flight check | რა აღმოაჩინა პანელმა რეპოზიტორიაში არასწორად |
| Rules | სრული სია, რომელსაც მოკლე ბლოკი აჯამებს |
boot თანმიმდევრობა ყველაზე სასარგებლო ნაწილია და ისეთი, რომელსაც ხელით არავინ წერს. ასისტენტს, რომელსაც ეკითხებიან "რატომ არ ეშვება ჩემი აპი", შეუძლია წაიკითხოს, რომ სერვერი ჯერ დამოკიდებულებებს აინსტალირებს, შემდეგ კონკრეტულ start ბრძანებას ასრულებს, და აქედან იმსჯელოს, Procfile-ის გამოგონების ნაცვლად. limits სექცია ამავე მიზეზით არის მნიშვნელოვანი: იმის ცოდნა, რომ პროცესი მეხსიერების ზღვარზე შეცდომის შეტყობინების გარეშე იკლავება - კონსოლი უბრალოდ ჩერდება - იდუმალ ავარიას ცხადი დიაგნოზად აქცევს. Node-ის მეხსიერების ლიმიტებზე ამის შესახებ დეტალურად წერია.
რას არ შეიცავს ფაილი განზრახ: deploy-ზე გასულ commit-სა და მის დროს. მათი ჩართვა ყოველ push-ს pull request-ის განახლებად აქცევდა, ანუ ზუსტად იმ ხმაურად, რაც არ გინდა.
საჯარო და პირადი რეპოზიტორიები#
პანელი ყოველი ჩაწერისას GitHub-ს ეკითხება, არის თუ არა რეპოზიტორია პირადი, და ყველაფერს, რაც აშკარა "private" არ არის, საჯაროდ თვლის. ორივეს განსხვავებული ფაილები ეძლევა.
| დეტალი | პირადი რეპო | საჯარო რეპო |
|---|---|---|
| წესები, boot ნაბიჯები, ლიმიტები | კი | კი |
| სერვერის მისამართი და პორტი | კი | მხოლოდ პორტის ცვლადი |
| დომენები, node, სერვერის ID | კი | არა |
| ცვლადების სახელები | კი | კი |
| ცვლადების მნიშვნელობები | არასაიდუმლო | არა |
| ბაზის host, სახელი, user | კი | მხოლოდ რაოდენობა |
საიდუმლო მნიშვნელობები არცერთ სახეობაში არასოდეს იწერება. საიდუმლოდ მონიშნული ცვლადი ჩნდება placeholder-ად, რომელიც ამბობს, რომ ის სერვერზეა დაყენებული და არ ჩანს, ბაზის პაროლები კი საერთოდ არ შედის - ფაილი ამბობს, რომ პაროლი Databases ჩანართზეა და .env-ში უნდა ინახებოდეს. ორივე ვერსია ასევე გადის იმავე redactor-ში, რომელსაც პანელის სხვა AI ფუნქციები იყენებს და რომელიც წმენდს ყველაფერს, რაც გასაღებს ან token-ს ჰგავს, და სერვერის ცნობილ საიდუმლოებს. ამას ბადედ ვახასიათებთ და არა დანაპირებად: ის იჭერს იმას, რისთვისაც შეიქმნა, და pull request-ს მაინც უნდა გადახედო merge-მდე, ისევე როგორც ნებისმიერს.
როგორ ერთვება pre-flight შედეგები context-ში#
GitHub ჩანართი pre-flight შემოწმებასაც ატარებს: კითხულობს რეპოზიტორიას - ერთი ხის სია და რამდენიმე პატარა ფაილი, არასოდეს კლონი - და ჩამოთვლის, რა გაფუჭდება სერვერის გაშვებისას, ყველაზე სერიოზულით დაწყებული, თითოეულს ჩასასმელი გამოსწორებით. ის ეძებს start სკრიპტის ან entry ფაილის არარსებობას, პორტ 3000-ის ან localhost-ის დაბმას სერვერის პორტის 0.0.0.0-ზე დაბმის ნაცვლად, framework-ს, რომელიც არასოდეს იგება (მაგალითად, .next არ არსებობს), .nvmrc-ში ან go.mod-ში დაფიქსირებულ runtime ვერსიას, Python-ის requirements-სა და entry ფაილს, Go-ს main პაკეტს, Bun-ისა და Deno-ს start tasks-ს, index ფაილს ვებ ჰოსტინგზე და commit-ში მოხვედრილ .env-ს, რომელიც სახელით ფიქსირდება და არასოდეს იხსნება.
როცა AI context-ის გადამრთველი ჩართულია, ეს აღმოჩენები .renode/server.md-ში ხვდება Pre-flight check-ის ქვეშ, შესავლით "What the panel found when it read this repository. Fix every FAIL first." თითოეული აღმოჩენა ერთი ხაზია, დონის დიდი ასოებით მითითებით, რასაც მოსდევს დეტალი და გამოსწორება:
## Pre-flight checkWhat the panel found when it read this repository. Fix every FAIL first.- [FAIL] No start script and no entry file - The server runs npm run start, and package.json has no start script. ... Fix: Add "start": "node <your main file>" to the scripts in package.json.სწორედ ეს ნაწილი ცვლის ასისტენტის ქცევას. მის გარეშე ხსნი Claude Code-ს ან Cursor-ს, წერ "deploy გაფუჭებულია, გამოასწორე", და ასისტენტი გამოცნობით იწყებს. მასთან ერთად ასისტენტი ხსნის რეპოზიტორიას, კითხულობს context ფაილს და პოულობს კონკრეტული პრობლემების სიას, გამოსწორებებიანად უკვე დაწერილს. პირველი ნაბიჯი ჩვეულებრივ ამ სიაში ჩასვლაა. დიაგნოსტიკა პანელმა გააკეთა, რედაქტირებას ასისტენტი აკეთებს, diff-ს შენ ამოწმებ.
ის წრეს ხურავს. შეასწორებ FAIL-ს, გააკეთებ push-ს და შემდეგი განახლება რეპოზიტორიას თავიდან წაიკითხავს. აღმოჩენა გაქრება, ფაილის შიგთავსი შეიცვლება და ღია pull request მის გარეშე ახალ commit-ს მიიღებს. სუფთა რეპოზიტორიას Pre-flight check სექცია საერთოდ არ აქვს.
განახლებულად შენახვა#
context განახლდება და არა ახირებით თავიდან გენერირდება. ფონური ამოცანა ყოველ ათ წუთში მუშაობს და ამჩნევს, როცა ცვლადები, პორტები, ბაზები ან დომენები იცვლება; GitHub ჩანართზე პარამეტრების შენახვაც აყენებს განახლებას რიგში, კავშირზე ათ წუთში მაქსიმუმ ერთს. ყოველ ჯერზე შიგთავსის hash-ი გამოითვლება და თუ ის წინასთან ემთხვევა, არაფერი იწერება. სერვერი, რომელიც არ იცვლება, commit-ებს არ ქმნის.
pull request-ს რა ემართება, მისი მდგომარეობითაა განსაზღვრული:
- ღია: ის ახალ commit-ს იღებს
renode/ai-context-ზე ცვლილებებით. - Merge-ული: ახალი pull request იხსნება მხოლოდ მაშინ, როცა შიგთავსი განსხვავდება იმისგან, რაც შენს branch-ზეა.
- დახურული merge-ის გარეშე: სტატუსი ამას ამბობს და ახალი იხსნება მხოლოდ მაშინ, როცა შიგთავსი ისევ შეიცვლება.
Update now ლოდინს ახტება და განახლებას მაშინვე უშვებს - გამოსადეგია App-ის ნებართვების დადასტურების შემდეგ ან პარამეტრის ისეთი ცვლილების შემდეგ, რომლის ფაილში დღესვე ნახვაც გინდა.
კავშირი სერვერის deploy პარამეტრებს მისდევს. deploy branch-ის შეცვლა pull request-ს ხურავს და ახალს ახალი branch-ის მიმართ ხსნის. სხვა რეპოზიტორიაზე გადართვა ფუნქციას თიშავს, რადგან ერთ რეპოზიტორიაში pull request-ებზე დათანხმება არ ნიშნავს სხვაში დათანხმებას. კავშირის გაუქმებაც ფუნქციას თიშავს. თუ გადამრთველს თავად გამორთავ, ღია pull request იხურება კომენტარით, ხოლო renode/ai-context branch იშლება. უკვე merge-ულს ის არასოდეს ეხება: ფაილები შენს რეპოზიტორიაში რჩება, სანამ თავად არ წაშლი.
პრობლემების მოგვარება#
სტატუსი ამბობს, რომ ნებართვას ელოდება. GitHub App-ს შენს installation-ზე არ მიუღია Contents და Pull requests write წვდომა. გაჰყევი ჩანართზე ბმულს installation-ის პარამეტრებამდე, დაადასტურე ახალი ნებართვები და დააჭირე Update now. სანამ ამას არ გააკეთებ, პანელი არაფერს წერს.
წერია, რომ რეპოზიტორიის განახლება ვერ მოხერხდა. წაიკითხე სტატუსის ხაზი და მასთან ერთად მიზეზი. გავრცელებულებია: რეპოზიტორია დაარქივებულია (GitHub ყველა ჩაწერას უარყოფს), GitHub-ის rate limit-ს მიაღწიე (დაელოდე და დააჭირე Update now), ან branch protection წესი renode/*-ს მოიცავს. შენი მთავარი branch-ის დაცვას მნიშვნელობა არ აქვს - პანელი იქ არასოდეს წერს - მაგრამ wildcard წესი, რომელიც renode/ai-context-საც ემთხვევა, დაბლოკავს.
ჩემს CLAUDE.md-ში start მარკერია, end მარკერი კი არა. პანელი არ იცნობს, სად მთავრდება მისი ბლოკი და არაფერს წერს. ეს ჩვეულებრივ ხელით რედაქტირების ან ცუდი merge-ის შემდეგ ხდება. წაშალე ზედმეტი მარკერი ან დაამატე დაკარგული და დააჭირე Update now.
ასისტენტი მაინც 3000 პორტზე იბმება. შეამოწმე, merge-ულია თუ არა pull request იმ branch-ში, რომელზეც ახლა ხარ. ფაილები მხოლოდ მაშინ მუშაობს, როცა ისინი იმ სამუშაო ასლშია, რომელსაც ასისტენტი ხსნის. შემდეგ შეამოწმე, რომ ხელსაწყო იმ ფაილს კითხულობს, რასაც ფიქრობ - Claude Code CLAUDE.md-ს კითხულობს, Codex და Cursor AGENTS.md-ს. ზოგი ხელსაწყო context-ს მხოლოდ სესიის დასაწყისში კითხულობს, ამიტომ დაიწყე ახალი.
არ მინდა პანელმა CLAUDE.md საერთოდ შეეხოს. დახურე pull request ან გამორთე გადამრთველი. თუ ინფორმაცია გინდა pull request-ის გარეშე, Console ჩანართის ზოლი "Work on this server with AI" გაძლევს ბმულს იმავე სერვერის context-ით, რომლის ასისტენტისთვის პირდაპირ მიცემაც შეგიძლია.
FAQ#
პანელი ოდესმე აკეთებს push-ს ჩემს main branch-ზე?
არა. ყოველი ჩაწერა renode/ai-context-ზე მიდის და შენს branch-ს მხოლოდ pull request-ით აღწევს, რომელსაც შენ merge-ს გააკეთებ. კოდი, რომელიც branch-ებს ამოძრავებს, renode/-ს გარეთ ნებისმიერ branch-ს უარყოფს, ამ branch-ებზე push-ები კი deploy-ს არასოდეს იწვევს.
pull request-ის merge სერვერს გადატვირთავს?
თუ deploy on push ჩართულია, merge შენს deploy branch-ზე ახალ commit-ს სვამს, ამიტომ კი, ის ისევე გადაიდეპლოვდება და გადაიტვირთება, როგორც ნებისმიერი სხვა push. თავად context ფაილები კოდის მუშაობას არაფერს ცვლის.
შემიძლია გენერირებული ფაილების რედაქტირება?
CLAUDE.md-სა და AGENTS.md-ს მარკერების გარეთ თავისუფლად ცვალე; პანელი ამ ტექსტს არ ეხება. არ შეცვალო .renode/server.md და ტექსტი მარკერებს შორის - შემდეგი განახლება გადაწერს. ამის ნაცვლად შეცვალე სერვერის პარამეტრები და ფაილი მიჰყვება.
ეს ChatGPT-ზე მუშაობს?
რეპოზიტორიით - არა. ბრაუზერში გახსნილი ChatGPT შენი GitHub-იდან ფაილებს თავისით არ კითხულობს. ჩატ-ასისტენტისთვის გამოიყენე Console ჩანართის ღილაკი Connect AI, რომელიც ქმნის share ბმულს სერვერის context-ით, და ის საუბარში ჩააკოპირე. Claude Code, Cursor, Copilot და Codex ის ხელსაწყოებია, რომლებიც რეპოზიტორიის ფაილებს თავისით იღებენ.
ჩემი ბაზის პაროლი ფაილშია?
არა, არც საჯარო და არც პირად რეპოზიტორიაში. პირადი რეპოზიტორია იღებს ბაზის სახელს, host-ს, პორტსა და user-ს, შენიშვნით, რომ პაროლი Databases ჩანართზეა და .env-ში უნდა ინახებოდეს. საჯარო იღებს მხოლოდ მიბმული ბაზების რაოდენობას.
რა ვქნა, თუ ჩემი რეპოზიტორია სერვერთან დაკავშირებული არ არის?
მაშინ პანელს აღსაწერი არაფერი აქვს და გადამრთველი არ გამოჩნდება. CLAUDE.md-სა და AGENTS.md-ს შენ მაინც შეგიძლია ხელით დაწერო ზემოთ მოცემული რჩევებით - სერვერის სექცია ის ნაწილია, რომელსაც ყველაზე მეტი ყურადღება უნდა დაუთმო.
