GSoC 1-р өдөр: Gemini CLI-д 7 issue нээж, 5 PR илгээсэн тухай

2026 оны 3 сарын 24. GSoC-ийн эхний ажлын өдөр. Би Gemini CLI-ийн #23331 epic дээр ажиллаж эхэлсэн. Behavioral eval бичих, баримтжуулалтын алдаа засах, contributor-уудад зориулсан skill хөгжүүлэх. Нэг өдрийн дотор 7 issue нээж, 5 PR илгээсэн. Энэ нийтлэлд тэр өдөр юу сурсан, юу алдсан, юу ойлгосон бүгдийг нь задлав.

issue нээсэн

PR илгээсэн

merge болсон

давхардсан issue

codebase

Gemini CLI-ийн дотоод бүтэц

Эхний хийсэн зүйл бол репозиторыг бүтнээр нь ойлгох гэж оролдсон. Monorepo, npm workspaces. Гол package-ууд:

packages/core

Backend логик

Prompt-ууд, tool тодорхойлолт, agent логик, MCP холболт, sandbox, skill систем. Бүх оюун ухаан энд байрлана. Миний ажлын ихэнх нь энэ package-д хамааралтай.

packages/cli

Terminal UI

React/Ink дээр бүтээсэн terminal interface. Хэрэглэгчийн input авах, output харуулах, tool дуудлагын зөвшөөрөл асуух зэрэг бүх UI логик.

packages/sdk

Programmatic API

Gemini CLI-г код дотроос дуудах боломж. CI/CD pipeline, автоматжуулалт, бусад tool-д embed хийхэд зориулсан.

packages/test-utils

TestRig

Behavioral eval ажиллуулах дэд бүтэц. evalTest болон appEvalTest helper-ууд энд. Миний eval бүгд үүнийг ашигласан.

Хөгжүүлэлтийн хэдэн чухал дүрэм:

Репо-ийн дүрмүүд

Node ~20.19.0 шаардлагатай. nvm use 20 ажиллуулах хэрэгтэй.

Commit message бүр conventional commits форматтай: type(scope): description (#issue)

Шинэ .ts файл бүрт Apache-2.0 лицензийн header заавал байх ёстой. ESLint шалгадаг.

PR бүр help-wanted label-тай issue-тэй холбоотой байх ёстой. Үгүй бол 14 хоногийн дараа автоматаар хаагдана.

Нэг хүнд хамгийн ихдээ 7 нээлттэй PR, 3 assigned issue зөвшөөрнө.

Fork workflow. Өөрийн fork руу push хийгээд, google-gemini/gemini-cli main руу PR нээнэ.

behavioral eval систем

Agent-ийн зан авирыг хэрхэн тестлэдэг вэ

Энэ бол миний GSoC ажлын гол сэдэв. Behavioral eval нь unit test биш. Функцийн буцаах утга зөв эсэхийг биш, agent зөв шийдвэр гаргаж байгаа эсэхийг шалгадаг.

Жишээ нь: Gemini файл засахын өмнө уншдаг уу? Алдаа гарахад өөрөө засах оролдлого хийдэг үү? Хэрэглэгчийн зөвшөөрөлгүй аюултай shell команд ажиллуулдаг уу? Эдгээрийг хүн нүдээр шалгахын оронд автоматжуулсан тест болгосон.

Хоёр helper бий:

evalTest

subprocess-based

Стандарт тест. Gemini CLI-г тусдаа process-д ажиллуулж, tool дуудлагуудыг лог хийж, assert шалгана. Ихэнх eval үүнийг ашигладаг.

appEvalTest

in-process

Ижил process дотор ажиллана. Breakpoint тавих, UI шалгах боломжтой. Гэхдээ README-д бүр баримтжуулаагүй байсан. Үүнийг би засав.

Eval ажиллуулахын өмнө заавал npm run build && npm run bundle хийх хэрэгтэй. Eval нь bundled CLI-г шалгадаг, source code-г биш. Энэ алхмыг мартаад хагас цаг алдсан.

Eval-ийн хамгийн чухал дүрэм нь "fail first". Eval бичихдээ эхлээд fail болох eval бичих ёстой. Дараа нь prompt-г засаж eval-г pass болгоно. Тухайн eval-г анхны ажиллуулалтаар шууд pass болгож бичвэл буруу гэж тооцдог. Яагаад гэвэл, шууд pass болох eval нь юуг ч батлахгүй, зүгээр л одоогийн байдлыг баримтжуулж байгаа.

Fail-first дүрэм

Eval бичихдээ эхлээд fail болох eval бичнэ. Дараа нь prompt/tool-г засаж pass болгоно. Шууд pass болох eval бичих нь "bad" гэж evals/README.md-д тодорхой бичсэн. Би энэ дүрмийг зөрчсөн. read-before-edit eval (#23588) анхнаасаа pass болсон. Энэ бол миний хийсэн алдаануудын нэг.

Tool log-ийн тухай: rig.readToolLogs() agent-ийн хийсэн бүх tool дуудлагыг буцаадаг. Нэр, аргумент (JSON string), амжилттай эсэх. Assert хийхдээ tool дуудлагын дарааллыг шалгана. Жишээ нь read tool-ийн index < edit tool-ийн index байвал agent файл уншаад дараа нь засаж байна гэсэн үг.

// tool log-оос read болон edit дуудлагын дарааллыг шалгах
const toolLogs = rig.readToolLogs();

const READ_TOOLS = ['read_file', 'read_many_files', 'grep_search'];
const EDIT_TOOLS = ['replace', 'write_file'];

const firstReadIndex = toolLogs.findIndex(
  log => READ_TOOLS.includes(log.name)
);
const firstEditIndex = toolLogs.findIndex(
  log => EDIT_TOOLS.includes(log.name)
);

// agent файл уншаад ДАРАА нь засах ёстой
expect(firstReadIndex).toBeLessThan(firstEditIndex);

Шөнийн nightly workflow eval-уудыг 6 модель дээр, тус бүр 3 удаа ажиллуулдаг. Гэхдээ локал орчинд олон модель дээр зэрэг ажиллуулах tool байгаагүй. Үүнийг би бүтээв.

илгээсэн ажлууд

5 PR-ийн задаргаа

Нэг өдөрт 5 PR. Бүгд нэг чиглэлтэй: eval системийн чанарыг сайжруулах.

read-before-edit behavioral eval

#23588 — issue #23586

Eval нь олон файлтай TypeScript проект бэлдэнэ. Нэг файлд нарийн алдаа оруулсан: буруу field reference. Agent уг файлыг уншихгүйгээр засаж чадахгүй. Тест нь tool log-оос read дуудлагын index < edit дуудлагын index эсэхийг шалгана.

Асуудал: fail-first дүрмийг зөрчсөн. Eval prompt өөрчлөлтгүйгээр шууд pass болсон.

evals/README.md баримтжуулалт засвар

#23592 — issue #23591, #23595

Хоёр асуудлыг нэг PR-д шийдсэн. Нэгдүгээрт, EvalCase Properties хэсэгт байхгүй log property баримтжуулсан, бодит property-ууд болох files, timeout, approvalMode орхигдсон. Хоёрдугаарт, appEvalTest helper 3 eval файлд ашиглагдаж байсан ч README-д нэг ч мөр баримтжуулалт байгаагүй.

Энэ бол merge болох магадлал хамгийн өндөртэй PR. Энгийн, тодорхой, review хийхэд хялбар.

Eval coverage analyzer skill

#23597 — issue #23596

Gemini CLI skill болгож бүтээсэн. .gemini/skills/eval-coverage-analyzer/ хавтаст байрладаг. Одоо байгаа eval файлуудыг сканнердаж, tool тодорхойлолт болон prompt-ийн зан авиртай cross-reference хийж, хаана eval дутуу байгааг тайлагнана. Аль хэдийн байсан behavioral-evals skill (ЯАГААД бичих гэдгийг заадаг) болон энэ skill (ЮУ бичих гэдгийг заадаг) бие биенээ нөхнө.

Log-to-eval conversion skill

#23599 — issue #23598

Chat session файлуудыг (~/.gemini/tmp/) уншаад eval scaffold автоматаар үүсгэдэг skill. Дотор нь scripts/parse-session.js script бий. Session JSON-г parse хийж, хэрэглэгчийн prompt, tool дуудлага, файл interaction зэргийг гаргаж авна. Бодит session файлууд дээр тестлэсэн.

Multi-model eval comparison script

#23607 — issue #23604

Issue-д асуудлыг нотолсон: ижил eval-г гараар хоёр модель дээр ажиллуулж, харьцуулах tool байхгүйг харуулсан. scripts/compare-eval-models.js бичсэн. Олон модель дээр eval ажиллуулж, comparison table + JSON report гаргана. GEMINI_MODEL env var-аар модель сольдог, nightly CI-тай ижил механизм.

Review-д олдсон bug: pass/fail логик atomic биш байсан. Засварласан. Одоо clean exit AND valid report AND дор хаяж нэг passing test гурвуулаа хэрэгтэй.

алдаанууд

Юу буруу хийсэн бэ

Алдааг нуух шаардлагагүй. Эхний өдөр яг хэдийд юу буруу болсныг бичье.

Давхардсан issue үүсгэсэн

read-before-edit eval (#23588) бичсэний дараа тусдаа issue (#23593) нээж, prompt-д read-before-edit guidance нэмэх санал тавьсан. Гэтэл eval аль хэдийн хийгдсэн. Юу хийгдсэн, юу хийгдээгүйг бүртгэлгүй ажилласнаас болсон.

Epic reference мартсан

Эхний хоёр PR-д Related to #23331 гэж бичихээ мартсан. Дараа нь буцаж нэмсэн. Maintainer-ууд PR-г epic-тай холбож tracking хийдэг учраас энэ чухал.

Fail-first дүрэм зөрчсөн

read-before-edit eval-г prompt өөрчлөлтгүйгээр бичсэн. Eval анхнаасаа pass болсон. Evals README-д үүнийг "bad" гэж тодорхой бичсэн байдаг. Prompt өөрчлөлттэй хослуулах хэрэгтэй байсан.

Codebase style зөрчсөн

processExitedCleanly гэж урт хувьсагчийн нэр бичсэн. Codebase-д exitOk гэх маягийн богино нэр ашигладаг. Review-д олдож, засарсан.

License header байнга алга болсон

Миний editor-ийн save hook Apache-2.0 license header-г strip хийж байсан. Commit бүрт дахин нэмэх шаардлагатай болсон. ESLint шалгаж байгаа учраас CI-д fail болно.

CLA-гүйгээр PR илгээсэн

Google-ийн репозиторт Contributor License Agreement заавал шаардлагатай. Эхний PR-аа CLA-гүйгээр илгээсэн. Bot шууд блоклосон. Дараа нь cla.developers.google.com-д ороод гарын үсэг зурсан.

сургамж

Цээжилсэн дүрмүүд

Эхний өдрийн алдаануудаас гарсан дүрмүүд. Цаашид давтахгүйн тулд бичиж авсан.

evals/README.md-г заавал уншаарай. Eval-тай холбоотой дурын ажлын өмнө. Fail-first дүрэм, USUALLY_PASSES policy, promotion процесс бүгд тэнд байна.
Issue болон PR бүрт "Related to #23331" бич. Epic tracking-д заавал хэрэгтэй. Мартвал буцаж засах хэрэгтэй болно.
Шинэ ажил эхлэхийн өмнө main руу checkout хий. Branch-ууд хоорондоо холилдохоос сэргийлнэ.
PR илгээхийн өмнө давхардал шалга. Одоо байгаа issue болон PR-уудыг нягтлан шалга. Шинэ issue нээхийн өмнө хайлт хий.
Issue-г PR-аас өмнө нээ. Том репозиторт контекстгүй PR maintainer-уудад ойлгомжгүй. Issue-д асуудлыг тайлбарлаад, PR-д reference-лэ.
[Google Summer of Code] prefix ашигла. GSoC-тай холбоотой бүх issue-д энэ prefix-г нэмэх хэрэгтэй.
help-wanted issue хайхыг бүү хүлээ. Одоо байгаа бүх help-wanted issue-ууд assigned байна. Codebase-г шинжилж, бодит gap олох хэрэгтэй.

epic #23331

GSoC зорилтуудын явц

Epic #23331-д 6 зорилт тодорхойлсон. Эхний өдрийн дараах байдал:

Зорилт	Төлөв	Ажил
#1 Onboarding, validation сурах	эхлээгүй
#2 Behavioral eval бичих	дууссан	PR #23588
#3 Skill/subagent хөгжүүлэх	хэсэгчлэн	PR #23597, #23599
#4 Gap илрүүлэх	дууссан	PR #23592
#5 Contributor tooling	дууссан	PR #23597, #23607
#6 Log-to-eval хөрвүүлэх	дууссан	PR #23599

6 зорилтоос 4 нь дууссан, 1 нь хэсэгчлэн, 1 нь эхлээгүй. Нэг өдрийн хувьд муу биш. Гэхдээ "дууссан" гэдэг нь PR илгээсэн гэсэн үг, merge болсон гэсэн үг биш. Бүгд review хүлээж байна.

Мөн #1 зорилт (onboarding, validation сурах) бол хамгийн чухал нь байж магадгүй. Eval бичих процессыг mentor-тэйгээ хамтдаа туулж, зөв арга барилыг эзэмших хэрэгтэй. Код бичихээс илүү хүнд ажил.

дараагийн алхам

Маргааш юу хийх вэ

Review feedback хүлээж байна. Зэрэгцээ хийх зүйлс:

Docs PR (#23592) дээр анхаарал төвлөрүүлэх. Хамгийн энгийн PR, merge болох магадлал өндөр. Эхний merge нь чухал, яагаад гэвэл contributor гэдгийг батална.
read-before-edit eval-г fail-first дүрэмд нийцүүлэх. Prompt өөрчлөлт нэмэх эсвэл eval-ийн шалгуурыг чангатгах хэрэгтэй. Mentor-ийн зөвлөгөөг хүлээнэ.
Multi-model script-ийн bug засвар (#23607). Pass/fail логикийг atomic болгосон ч бусад edge case байж магадгүй.
Onboarding зорилт (#1) эхлэх. Validation процессыг бүтнээр нь туулж, баримтжуулах. Бусад contributor-уудад зориулсан guide бичих.

gsoc 2026 -- day 1 -- gemini cli -- epic #23331

Эхний өдөр олон юм хийсэн, олон алдаа гаргасан. Гэхдээ алдаа бүр нэг зүйл заасан. CLA мартсанаас CONTRIBUTING.md-г бүтнээр унших хэрэгтэй гэдгийг, давхардсан issue-ээс хийсэн зүйлээ бүртгэх хэрэгтэй гэдгийг, fail-first зөрчсөнөөс eval бичихийн өмнө README уншихыг. Цаашид энэ цувралд review feedback, merge процесс, болон eval бичих бодит workflow-ийн тухай бичнэ. Contributor Registration 3-р сарын 31-нд хаагдана. Хэрвээ GSoC сонирхож байвал summerofcode.withgoogle.com-д бүртгүүлээрэй.