Codex vs Kode Claude: Agen Pengkodean Mana yang Cocok untuk Alur Kerja Anda?

Perbandingan antara Codex dan Claude bukanlah sekadar mencari satu pemenang yang universal, melainkan lebih kepada memilih gaya kerja yang dapat Anda andalkan setiap hari. Kedua produk tersebut mampu memeriksa repositori, mengedit beberapa berkas sekaligus, menjalankan perintah, melaksanakan pengujian, dan menjelaskan sebuah patch. Perbedaan yang signifikan terlihat pada cara Anda mendelegasikan pekerjaan, seberapa sering Anda mengarahkan agen, seberapa banyak bukti yang dapat Anda periksa, serta sejauh mana masing-masing alat tersebut sesuai dengan lingkungan pengembangan yang sudah ada.

Dalam uji repositori terkontrol dengan empat tugas yang kami lakukan, Codex memperoleh skor 98/100 dan Claude Code memperoleh skor 99/100. Keduanya menyelesaikan tugas inti. Claude Code menunjukkan cakupan tinjauan yang lebih luas dan penanganan kasus tepi yang lebih baik, sementara Codex sering kali mencapai hasil yang diperlukan dengan cakupan yang lebih sempit dan menghasilkan bukti tingkat eksekusi yang lebih kuat dalam pengaturan kami. Perbedaan satu poin pada fixture Python yang kecil bukanlah alasan untuk menyatakan pemenang secara mutlak.

Pengembang yang tidak ingin alur kerja mereka yang lain terikat pada satu agen pemrograman dapat menambahkan GlobalGPT sebagai lapisan multi-model dan multimodal yang terpisah. GlobalGPT mengintegrasikan lebih dari 100 model teratas, seperti GPT 5.6, Claude Opus 5, dan GPT Image 2, dalam satu dasbor. Selain itu, GlobalGPT CLI, Jalur MCP dan Skill dapat digunakan melalui Codex atau Kode Claude untuk mendapatkan pendapat kedua, perencanaan, dokumentasi, atau model-model lain yang didukung, sementara host pengkodean asli tetap memegang kendali atas pengeditan repositori dan pengujian.

Coba Lebih dari 100 Model Terbaik di GlobalGPT

Perbandingan ini menggabungkan informasi rencana resmi, pekerjaan langsung pada repositori, hasil yang lengkap dan dapat diperluas, serta pengalaman komunitas yang dijelaskan dengan jelas. Tujuannya adalah untuk membantu pengembang independen memilih platform pemrograman utama tanpa harus bingung dengan akses berlangganan, kredit tambahan, dan penagihan API.

Perbandingan Singkat Antara Codex dan Kode Claude

Tabel ini menggambarkan keputusan pembelian, bukan daftar peringkat model. Pengaturan model, repositori, konfigurasi izin, atau spesifikasi tugas yang berbeda dapat mengubah hasilnya. Jika Anda sudah menggunakan salah satu produk, perbandingan terbaik adalah dengan menggunakan tugas terbatas dari basis kode Anda sendiri yang menggunakan perintah keberhasilan yang sama dan tanpa pengulangan penilaian kualitas.

Apa sebenarnya yang dimaksud dengan Codex dan Kode Claude

Codex dan Claude Code adalah produk agen, bukan sekadar nama model. Yang mendasarinya Model AI untuk pemrograman Memang penting, tetapi kerangka kerja yang mengelilinginya juga menentukan file mana saja yang dapat dilihat oleh agen, perintah apa saja yang boleh dijalankan, bagaimana proses persetujuan berlangsung, bagaimana konteks dipertahankan, dan bukti apa saja yang tersisa setelah tugas selesai. Membandingkan hanya reputasi model saja berarti mengabaikan sebagian besar pengalaman yang dibeli oleh seorang pengembang.

Codex mencakup alur kerja berbasis baris perintah, IDE, desktop, dan berbasis cloud. Cakupan tersebut membuatnya cocok baik untuk kolaborasi lokal langsung maupun pendelegasian tugas yang lebih terstruktur. Claude Code berfokus pada alur kerja terminal berbasis percakapan dengan integrasi yang didukung serta ruang penyesuaian yang luas; hal ini panduan penggunaan Claude untuk pemrograman memberikan pengenalan yang lebih luas mengenai alur kerja tersebut. Bagi sebagian pengembang, melihat agen bekerja di terminal dapat memberikan rasa tenang. Bagi yang lain, hal yang penting adalah hasil perbandingan akhir, uji coba, dan jejak audit, bukan percakapan yang berlangsung terus-menerus.

Perbedaan ini juga menjelaskan mengapa dua pengujian yang menggunakan model yang secara nominal kuat dapat menunjukkan perilaku yang berbeda. Pihak pengelola menentukan bagaimana instruksi disajikan, bagaimana alat-alat dipanggil, dan kapan seorang manusia harus menyetujui suatu tindakan. Perbandingan antar-komunitas yang mengabaikan kerangka pengujian dapat salah mengartikan perilaku pada tingkat produk sebagai kebenaran pada tingkat model.

• Model menyediakan kemampuan penalaran dan pembangkitan.
• Sistem pengikat agen mengelola berkas, perintah, konteks, persetujuan, dan pemulihan.
• Kontrak tugas pengguna menentukan cakupan, pemeriksaan keberhasilan, dan kapan agen harus berhenti.

Alur kerja dan pengendalian: pendelegasian atau pengarahan berkelanjutan?

Pertanyaan paling berguna mengenai perbandingan Codex dan Claude seringkali bukanlah “Manakah yang menghasilkan kode yang lebih baik?” melainkan “Bagaimana saya ingin menggunakannya?” Tugas yang jelas dan terbatasi dapat didelegasikan dengan tujuan yang tepat, ruang lingkup yang diizinkan, dan perintah verifikasi. Refaktorisasi yang ambigu akan lebih baik jika disertai diskusi, pemeriksaan berkala, dan kesempatan untuk mengarahkan kembali agen sebelum perubahan yang dilakukan menjadi terlalu besar.

Pengawasan berkelanjutan sangat berguna ketika persyaratan terus berkembang atau pertimbangan arsitektural masih dalam tahap pembahasan. Hal ini justru menjadi beban ketika agen berulang kali meminta keputusan yang sebenarnya dapat diselesaikan berdasarkan instruksi dari repositori. Pelaksanaan otonom sangat berguna ketika kontrak tugas sudah stabil. Hal ini menjadi berisiko ketika agen membuat asumsi yang tidak terverifikasi atau memperluas cakupan tanpa jalur rollback yang jelas.

Sebuah laporan terperinci di Reddit tertanggal 13 April 2026 menggambarkan pengalaman sekitar 100 jam menggunakan Claude Code dan 20 jam menggunakan Codex pada proyek Python dan TypeScript yang terdiri dari sekitar 80.000 baris kode dengan sekitar 2.800 tes. Penulis menggambarkan Claude sebagai alat yang lebih cepat dan lebih interaktif, namun membutuhkan pengawasan yang lebih intensif, sedangkan Codex dianggap lebih lambat dan lebih teliti. Laporan tersebut sangat bermanfaat karena mencakup konteks proyek dan pengalaman, namun tetap mewakili alur kerja seorang pengembang saja.

Hasil pengukuran waktu kami sendiri tidak menunjukkan pemenang yang jelas. Claude menyelesaikan dua tugas pertama lebih cepat, sementara Codex menyelesaikan dua tugas terakhir lebih cepat. Claude juga menggunakan subagen cadangan setelah jalur otentikasi CLI-nya tidak tersedia, sehingga jalur eksekusinya tidak setara dengan kondisi laboratorium. Kesimpulan yang tepat adalah bahwa kecepatan bergantung pada tugas, model yang dipilih, pengaturan upaya, konteks, dan host—bukan berarti salah satu produk selalu lebih cepat.

Pemahaman terhadap repositori dan pengelolaan konteks

Pemahaman terhadap repositori lebih dari sekadar memberi nama folder. Sebuah agen yang berguna harus dapat melacak pergerakan data antar berkas, mengidentifikasi kontrak yang membatasi suatu perubahan, menemukan uji coba, membedakan gejala dari sumber yang kemungkinan besar menjadi penyebabnya, serta menjelaskan risiko mengedit lapisan yang salah. Peta yang lengkap dapat mengungkap ketidakkonsistenan yang tersembunyi; sedangkan peta yang ringkas dapat membantu pengembang mencapai keputusan implementasi yang aman dengan lebih cepat.

Dalam tugas T1 mode baca-saja kami, kedua agen memperoleh skor 20/20 dan mendasarkan jawaban mereka pada repositori. Kode Claude lebih mendetail dan mengungkap ketidakkonsistenan kontrak tambahan. Codex lebih ringkas namun tetap mengidentifikasi berkas-berkas yang relevan, risiko, dan rencana implementasi. Tidak ada satu gaya pun yang secara otomatis lebih unggul. Kelengkapan berguna selama migrasi dan audit yang belum dikenal; sedangkan kesederhanaan berguna ketika pengembang sudah memahami arsitektur dan menginginkan rencana perubahan yang terfokus.

Arsitektur: model, repositori, layanan, dan utilitas waktu tanpa koneksi.

Risiko utama: semantik prioritas yang tidak jelas, masalah kompatibilitas, urutan, validasi, dan ketidaksesuaian cakupan.

Tiga lapisan ditambah satu modul terpisah. Tanpa siklus; injeksi ketergantungan minimal.

Hal ini juga mengungkap masalah alokasi pengenal, kontrak kesalahan asimetris, dan cakupan pengujian yang minim.

Arsitektur ##

Ini adalah paket Python kecil yang hanya menggunakan pustaka standar, dengan empat lapisan fungsional:

- **Model data:** [`Job`]() adalah kelas data yang tidak dapat diubah (immutable) yang berisi `identifier`, `name`, dan `owner`. `Job.to_dict()` menserialisasikannya melalui `dataclasses.asdict()`.
- **Repositori:** [`JobRepository`]() menyimpan pekerjaan dalam kamus dalam memori yang dikunci berdasarkan pengenal. Tidak ada basis data atau penyimpanan permanen.
- **Layanan:** [`SchedulerService`]() bertanggung jawab atas alokasi `identifier`, normalisasi input, pembuatan, pencatatan, dan penghapusan.
- **Utilitas waktu:** [`next_daily_run()`]() menghitung waktu eksekusi berikutnya, tetapi tidak ada yang mengimpor atau menghubungkannya ke `Job`, `SchedulerService`, atau `JobRepository`.
- **API Publik:** [`scheduler.__init__`]() hanya mengekspor `SchedulerService`.

Terlepas dari nama repositori, pekerjaan saat ini tidak mengandung informasi penjadwalan, dan tidak ada antrian eksekusi. Oleh karena itu, prioritas dapat memengaruhi metadata yang disimpan dan urutan pencatatan, tetapi tidak dapat memengaruhi eksekusi pekerjaan yang sebenarnya tanpa memperluas sistem secara signifikan.

## Alur data pembuatan dan pencatatan

Pembuatan melalui `SchedulerService.create_job(name, owner)`:

1. [`create_job()`]() menolak nama yang hanya berisi spasi.
2. Fungsi ini memotong `name` dan `owner`, lalu membuat objek `Job` yang tidak dapat diubah (immutable) menggunakan `_next_identifier` dari layanan tersebut.
3. [`JobRepository.save()`]() menyimpan objek tersebut ke `_jobs[job.identifier]`.
4. Layanan ini menambah nilai `_next_identifier` dan mengembalikan objek `Job` yang sama.

Menampilkan daftar melalui `SchedulerService.list_jobs()`:

1. [`list_jobs()`]() mendelegasikan langsung ke `repository.all()`.
2. [`JobRepository.all()`]() mengurutkan kunci kamus secara numerik.
3. Oleh karena itu, pekerjaan dikembalikan dalam urutan pengidentifikasi/pembuatan yang naik, bukan urutan jadwal atau prioritas.

## Berkas-berkas yang kemungkinan terpengaruh oleh prioritas pekerjaan

Diperlukan:

- [`scheduler/models.py`](): tambahkan bidang prioritas beserta nilai defaultnya. `to_dict()` akan secara otomatis menyertakannya karena menggunakan `asdict()`.
- [`scheduler/service.py`](): terima, validasi, dan serahkan prioritas ke `Job`.
- [`tests/test_scheduler.py`](): uji perilaku nilai default, eksplisit, tidak valid, serialisasi, dan urutan.

Kondisional:

- [`scheduler/repository.py`](): ubah `all()` hanya jika prioritas dimaksudkan untuk mengontrol urutan daftar. Kunci sekunder yang deterministik seperti `identifier` harus menangani kasus seri.
- [`scheduler/__init__.py`](): perbarui hanya jika prioritas menjadi enum publik atau objek nilai.
- [`README.md`](): dokumentasikan nilai-nilai yang diterima, nilai default, dan semantik urutan.

Mungkin tidak terpengaruh:

- `scheduler/time_rules.py`, karena simbolnya hanya beroperasi pada datetime yang disediakan dan tidak memiliki hubungan dengan pekerjaan atau penampilan daftar.

## Risiko utama

- **Semantik yang tidak terdefinisi:** Kode ini tidak memberikan pedoman apakah nilai yang lebih besar atau lebih kecil berarti prioritas yang lebih tinggi, nilai mana yang valid, atau apakah prioritas memengaruhi urutan daftar sama sekali.
- **Kompatibilitas:** Menambahkan argumen wajib ke `Job` atau `create_job()` akan merusak pemanggil yang sudah ada, seperti `create_job("Daily report", "Alex")` dalam tes saat ini. Nilai default akan mempertahankan panggilan tersebut.
- **Kerusakan konstruktor posisional:** `Job` saat ini dibuat secara posisional di `SchedulerService.create_job()`. Penempatan bidang dan panggilan posisional di masa depan dapat secara diam-diam menetapkan nilai yang salah; konstruksi berbasis kata kunci akan lebih aman.
- **Perubahan urutan:** Mengganti urutan pengenal dalam `JobRepository.all()` akan mengubah perilaku yang sudah mapan. Prioritas yang sama memerlukan penentu pemecah seri yang stabil.
- **Ambiguitas validasi:** Nilai Python yang tidak dibatasi dapat memungkinkan string, boolean, atau bilangan bulat sembarang yang sulit dibandingkan secara konsisten.
- **Ketidaksesuaian lingkup eksekusi:** Tidak ada dispatcher atau antrian eksekusi. Klaim bahwa prioritas menentukan pekerjaan mana yang dieksekusi terlebih dahulu tidak didukung oleh simbol apa pun saat ini.
- **Keterbatasan dalam memori:** Prioritas, seperti bidang pekerjaan lainnya, akan hilang saat proses berakhir karena `_jobs` hanyalah sebuah kamus instance.

## Rencana implementasi dan validasi

1. Tentukan kontrak terlebih dahulu: representasi, nilai yang diizinkan, nilai default, arah prioritas, penentuan pemenang saat seri, dan apakah hal ini mengubah urutan daftar.
2. Tambahkan `priority` ke `Job`, sebaiknya dengan nilai default yang kompatibel ke belakang.
3. Perluas `SchedulerService.create_job()` dengan parameter prioritas yang telah diberi nilai default, validasi parameter tersebut, dan buat objek `Job` menggunakan argumen kata kunci.
4. Jika urutan daftar mempertimbangkan prioritas, ubah `JobRepository.all()` agar mengurutkan berdasarkan prioritas terlebih dahulu, diikuti oleh pengenal. Jika tidak, biarkan urutan repositori tetap tidak berubah.
5. Tambahkan pengujian untuk:
   - Pembuatan dengan dua argumen yang sudah ada.
   - Pelestarian prioritas eksplisit.
   - Prioritas default.
   - Tipe yang tidak valid dan nilai di luar rentang.
   - Keluaran `Job.to_dict()`.
   - Urutan daftar dengan prioritas ganda.
   - Urutan yang stabil untuk prioritas yang sama.
   - Perilaku nama kosong yang sudah ada.
6. Perbarui README dengan kontrak publik yang tepat.
7. Jalankan rangkaian uji offline lengkap dengan `python3 -m unittest discover -s tests -v`.

## Verifikasi telah dilakukan

- Rangkaian uji dasar: **2 uji lulus**.
- Pencarian simbol di seluruh repositori memastikan bahwa `next_daily_run()` tidak terhubung dan tidak ada simbol prioritas yang ada.
- File yang diubah: **tidak ada**.
- Implementasi fitur: **belum dilakukan**, sesuai persyaratan.

> **Kesimpulan + keputusan**
>
> Perubahan ini kecil jika prioritas hanya berupa metadata atau urutan daftar: terutama `models.py`, `service.py`, `repository.py`, dan tes. Sebelum implementasi, keputusan yang diperlukan adalah apakah prioritas hanya mendeskripsikan suatu pekerjaan atau mengubah urutan `list_jobs()`, ditambah skala nilai, nilai default, arah, dan aturan pemecahan seri.

Catatan Eksekusi # T1 — Pemahaman Repositori yang Tidak Dikenal

Parameter Eksekusi ##

| Kolom | Nilai |
| --- | --- |
| Tugas | `T1` |
| Prompt yang Dibekukan | `01-prompts/T1.md` |
| SHA-256 prompt yang dibekukan | `a571ff15c2502ec29b172ae2e77dd9ab0caca2869b91f9468d47571434d16c17` |
| Unit eksekusi | subagen Claude yang terisolasi, `general-purpose`, konteks baru |
| Metode isolasi | **fallback subagen** (penurunan versi yang terdokumentasi — lihat `results/isolation-decision.md`) |
| Salinan bersih yang ditugaskan | `runtime/workspaces/T1` |
| Versi kode Claude | `2.1.220` |
| Pengaturan model | `claude-opus-5` |
| start_utc | `2026-07-28T10:27:31Z` |
| end_utc | `2026-07-28T10:28:32Z` |
| Durasi | 61 detik (bersamaan dengan T2–T4; bukan pengukuran latensi yang murni) |
| Nomor percobaan | 1 |
| Status | `valid` |
| Intervensi manusia | tidak ada |

## Ringkasan alat aman

`date`, `find`, `ls`, `wc`, `stat`, `grep`, `Read` pada 7 berkas ruang kerja, `python3 -V`,
`python3 -m unittest discover -s tests -v`. Semua pembacaan terbatas pada ruang kerja yang ditetapkan.
Tanpa jaringan, tanpa instalasi, tanpa penulisan.

## Hasil pemeriksaan offline

`python3 -m unittest discover -s tests -v` → 2 tes, OK (keluar 0). Diverifikasi ulang oleh
koordinator dari luar ruang kerja: lihat `results/checks/T1-public.txt`.

## Patch

Tidak ada. `results/T1/patch.diff` kosong, dan `diff -ru 02-fixture runtime/workspaces/T1`
tidak menunjukkan perbedaan apa pun. Tugas ini memerlukan pemeriksaan tanpa mengubah berkas; hal ini
telah dikonfirmasi, bukan hanya dinyatakan.

## Kesalahan yang telah diperbaiki

Satu kesalahan shell yang dapat diperbaiki: perintah `grep` awal menggunakan pola `--include=*.py` tanpa tanda kutip yang
dicoba di-glob oleh shell; dijalankan ulang dengan pola yang diberi tanda kutip dan berhasil. Tidak ada dampak pada temuan.

## Keluaran yang terlihat (verbatim)

### 1. Apa itu repositori ini

Sebuah fixture pustaka standar Python yang mandiri bernama `local-scheduler-1.0.0` (`fixture-manifest.json`), berlisensi MIT, tanpa ketergantungan jaringan atau produksi (`README.md`, `"network_required": false`). Repositori ini sangat kecil: 8 berkas sumber/dokumentasi ditambah manifes, total 103 baris. Interpreter yang digunakan adalah **Python 3.9.6**. Tidak ada `pyproject.toml`, `setup.py`, konfigurasi CI, linter, atau konfigurasi pemeriksa tipe — satu-satunya alur kerja yang dinyatakan adalah `python3 -m unittest discover -s tests -v` (`README.md`).

### 2. Arsitektur

Tiga lapisan ditambah satu modul terpisah, semuanya berada di bawah `scheduler/`:

| Lapisan | Berkas | Simbol | Tanggung Jawab |
|---|---|---|---|
| Fasad paket | `scheduler/__init__.py` | `__all__ = ["SchedulerService"]` | Hanya mengekspor ulang `SchedulerService`; `Job`, `JobRepository`, dan `time_rules` bukan bagian dari antarmuka publik |
| Model domain | `scheduler/models.py` | `Job` (`@dataclass(frozen=True)`) | Objek nilai yang tidak dapat diubah (immutable) dengan bidang `identifier: int`, `name: str`, `owner: str`, ditambah `to_dict()` yang diimplementasikan sebagai `asdict(self)` |
| Persistensi | `scheduler/repository.py` | `JobRepository` | `dict` dalam memori yang menggunakan identifier sebagai kunci; `save`, `get`, `all`, `delete` |
| Layanan aplikasi | `scheduler/service.py` | `SchedulerService` | Validasi, alokasi pengenal, orkestrasi: `create_job`, `list_jobs`, `delete_job` |
| Orphan | `scheduler/time_rules.py` | `next_daily_run` | Perhitungan pengulangan — **tidak diimpor oleh apa pun** |

Arah ketergantungan jelas dan satu arah: `service.py` mengimpor dari `.models` dan `.repository`; `repository.py` mengimpor dari `.models`; `models.py` hanya mengimpor `dataclasses`. Tidak ada siklus. Injeksi ketergantungan ada tetapi minimal — `SchedulerService.__init__(self, repository=None)` melakukan `self.repository = repository or JobRepository()`, sehingga repositori palsu dapat disubstitusikan dalam pengujian.

Perhatikan bahwa `scheduler/time_rules.py` saat ini merupakan kode mati. Saya telah mencari `time_rules` dan `next_daily_run` di seluruh pohon direktori; hasil yang ditemukan hanyalah definisi kodenya sendiri dan pencantumannya di `expected_files` dalam `fixture-manifest.json`. Kode tersebut telah disertakan tetapi tidak terhubung.

### 3. Alur data

**Membuat pekerjaan** — `SchedulerService.create_job(name, owner)`:
1. Pemeriksaan: `if not name.strip(): raise ValueError('name is required")`. Ini adalah *satu-satunya* validasi dalam sistem — `owner` tidak pernah diperiksa, sehingga pemilik yang kosong diterima.
2. Konstruksi: `Job(self._next_identifier, name.strip(), owner.strip())` — konstruksi posisional, dan kedua string dinormalisasi dengan menghapus spasi.
3. Persist: `self.repository.save(job)`, yang melakukan `self._jobs[job.identifier] = job` dan mengembalikan objek `Job`.
4. Meningkatkan nilai counter: `self._next_identifier += 1` — *setelah* penyimpanan, sehingga jika terjadi pengecualian, nilai counter tidak akan terpakai.
5. Mengembalikan instance `Job` (layanan mengembalikan `job` lokalnya sendiri, bukan nilai kembalian dari repositori).

Alokasi pengenal berada di dalam **layanan**, bukan di repositori (`self._next_identifier = 1` di `SchedulerService.__init__`). Ini merupakan titik sambungan yang penting: menyuntikkan repositori yang sudah berisi pekerjaan akan secara diam-diam menimpa pekerjaan tersebut, karena layanan baru akan memulai penomoran ulang dari 1.

**Menampilkan daftar pekerjaan** — `SchedulerService.list_jobs()` merupakan panggilan langsung ke `JobRepository.all()`, yang mengembalikan `[self._jobs[key] for key in sorted(self._jobs)]`. Oleh karena itu, urutannya adalah **meningkat berdasarkan pengenal bilangan bulat**, yang saat ini sama dengan urutan penyisipan. Daftar baru dibuat pada setiap panggilan, tetapi objek `Job` merupakan referensi bersama — aman hanya karena `Job` dibekukan.

**Penghapusan** — `SchedulerService.delete_job(identifier)` mendelegasikan ke `JobRepository.delete`, yang merupakan `self._jobs.pop(identifier)` tanpa nilai default, sehingga akan memicu `KeyError` jika ID tidak ditemukan. Hal ini tidak konsisten dengan `JobRepository.get`, yang mengembalikan `None` untuk kondisi yang sama.

**Cakupan pengujian untuk jalur-jalur ini** — `tests/test_scheduler.py` memiliki tepat dua kasus: `test_create_and_list_jobs` (memverifikasi `job.identifier == 1` dan `[job] == service.list_jobs()`) serta `test_blank_name_is_rejected`. Keduanya lulus pada struktur pohon saat ini.

### 4. Berkas yang kemungkinan terpengaruh oleh penambahan prioritas pekerjaan

Dalam urutan kepastian menurun:

1. **`scheduler/models.py`** — pasti. `Job` memerlukan bidang `priority`. Karena dataclass-nya `frozen=True` dan bidangnya bersifat posisional, bidang baru harus memiliki nilai default (misalnya `priority: int = 0`) atau harus ditempatkan setelah tiga bidang yang sudah ada; jika tidak, setiap konstruksi posisional yang ada akan rusak. `to_dict()` tidak memerlukan pengeditan — `asdict(self)` secara otomatis mengambil bidang tersebut, yang merupakan perubahan kontrak serialisasi tanpa pemberitahuan, bukan perubahan kode.
2. **`scheduler/service.py`** — pasti. `create_job` memerlukan parameter `priority` dan harus meneruskannya ke konstruktor posisional `Job(...)` pada baris 13. Jika prioritas divalidasi (rentang, keanggotaan enum), pengecekan tersebut harus ditempatkan di samping pengecekan `name.strip()` yang sudah ada. Jika daftar harus diurutkan berdasarkan prioritas, `list_jobs` adalah tempat kebijakan pengurutan akan ditempatkan jika Anda ingin repositori tetap menjadi penyimpanan sederhana.
3. **`scheduler/repository.py`** — kemungkinan besar. `sorted(self._jobs)` pada `JobRepository.all()` mengurutkan *kunci* kamus, yaitu pengenal. Daftar yang diurutkan berdasarkan prioritas memerlukan perubahan ini untuk mengurutkan nilai berdasarkan kunci seperti `(-job.priority, job.identifier)`, atau menambahkan aksesor terurut terpisah. Jangan biarkan pemecahan seri secara implisit: urutan penyisipan kamus bukanlah kontrak yang stabil untuk diandalkan.
4. **`tests/test_scheduler.py`** — pasti. Kasus-kasus baru untuk prioritas default, prioritas eksplisit, pengurutan, dan penolakan prioritas yang tidak valid. Perhatikan bahwa `assertEqual([job], service.list_jobs())` yang ada membandingkan objek *yang sama*, sehingga tetap berfungsi meskipun ada penambahan bidang; hal ini tidak akan berfungsi jika membandingkan literal `Job` yang baru dibuat.
5. **`README.md`** — kemungkinan besar, jika semantik prioritas (ujung rentang mana yang menang, nilai default) perlu disebutkan di mana pun.
6. **`scheduler/__init__.py`** — hanya jika enum prioritas atau konstanta perlu diekspor bersama `SchedulerService`.
7. **`fixture-manifest.json`** — hanya jika Anda menambahkan berkas modul baru; array `expected_files`-nya merupakan inventaris eksplisit dan akan berubah.
8. **`scheduler/time_rules.py`** — *tidak* boleh diubah. Prioritas bersifat ortogonal terhadap kekambuhan, dan modul ini tidak terhubung.

### 5. Risiko Utama

- **Semantik pengurutan merupakan perubahan perilaku yang tidak terdeteksi.** `JobRepository.all()` saat ini menjamin urutan pengenal naik, dan `list_jobs` mewarisi hal tersebut. Setiap pengguna yang mengandalkan jaminan tersebut akan mengalami gangguan akibat pengurutan ulang. Tentukan secara eksplisit: apakah `list_jobs()` berubah maknanya, ataukah akan muncul `list_jobs_by_priority()` baru di sampingnya? Opsi pertama berisiko lebih tinggi dan tes yang ada `test_create_and_list_jobs` terlalu lemah untuk mendeteksi regresi (daftar dengan satu elemen).
- **Arah penyortiran benar-benar ambigu.** "Prioritas 1' secara konvensional berarti *tertinggi* di beberapa sistem dan *terendah* di sistem lainnya. Tidak ada apa pun di repositori ini — tidak ada komentar, tidak ada docstring, tidak ada baris di README — yang menjelaskannya. Pilih sebuah konvensi, dokumentasikan di `models.py`, dan terapkan dalam tes dengan setidaknya tiga prioritas yang berbeda agar arahnya ditetapkan.
- **Sortir yang tidak stabil pada nilai yang sama.** Jika dua pekerjaan memiliki prioritas yang sama, hasilnya tetap harus deterministik. Fungsi `sorted` di Python bersifat stabil, tetapi stabilitas hanya berguna jika urutan masukan itu sendiri telah didefinisikan. Selalu sertakan `identifier` sebagai kunci sekunder yang eksplisit.
- **Urutan bidang pada dataclass yang dibekukan.** `Job` adalah `@dataclass(frozen=True)` dengan tiga bidang posisional, dan `service.py:13` mengkonstruksinya secara posisional. Menyisipkan `priority` di mana pun selain di posisi terakhir, atau tanpa nilai default, merupakan perubahan yang merusak (breaking change) yang mungkin tidak terdeteksi dengan jelas oleh dua tes yang sudah ada.
- **Perluasan kontrak `to_dict()`.** `asdict(self)` mencerminkan semua bidang. Menambahkan `priority` mengubah setiap muatan yang diserialisasikan tanpa perubahan yang terlihat pada badan metode di `models.py`. Apa pun yang mengandalkan bentuk kamus yang tepat akan mengalami kegagalan.
- **Batasan Python 3.9.6.** Tidak ada `@dataclass(slots=True)` (3.10+), tidak ada `kw_only=True` (3.10+), dan anotasi PEP 604 `int | None` akan gagal saat runtime tanpa `from __future__ import annotations`. Jika prioritas dimodelkan sebagai enum, `enum.StrEnum` hanya tersedia mulai versi 3.11+ dan tidak tersedia saat ini. Salah satu dari hal ini akan menyebabkan fixture gagal pada interpreter ini.
- **Alokasi pengenal berada di lapisan yang salah.** `SchedulerService._next_identifier` berarti layanan tersebut mengelola pembangkitan ID sementara repositori mengelola penyimpanan. Jika pengembangan prioritas mendorong implementasi repositori kedua atau fixture yang dimuat sebelumnya, pemisahan ini akan menyebabkan tabrakan ID dan pekerjaan yang ditimpa.
- **Kontrak kesalahan yang asimetris.** `JobRepository.get` mengembalikan `None` jika tidak ditemukan, sedangkan `JobRepository.delete` memicu `KeyError`. Setiap pencarian baru yang terkait dengan prioritas harus secara sengaja memilih satu konvensi, bukan secara tidak sengaja mewarisi ketidakkonsistenan tersebut.
- **Preseden celah validasi.** `create_job` memvalidasi `name` tetapi tidak `owner`. Jangan meniru kelonggaran tersebut untuk `priority` — prioritas yang tidak tervalidasi akan diteruskan ke kunci pengurutan dan dapat memicu `TypeError` jauh di dalam `sorted` (misalnya, membandingkan `int` dengan `None`) alih-alih di lokasi panggilan.
- **Perangkap kode mati.** `scheduler/time_rules.py` tampak seperti logika penjadwalan dan akan menarik perhatian untuk diedit. Berkas ini tidak diimpor oleh apa pun, dan docstring-nya sendiri mengakui adanya bug: berkas ini menambahkan 24 jam yang telah berlalu dalam UTC dan "menggeser waktu jam dinding lokal selama transisi waktu musim panas." Mengubahnya tidak menghasilkan efek yang dapat diamati pada sistem yang diuji, sehingga upaya yang dihabiskan di sana sia-sia dan setiap tes yang ditulis untuk mengujinya tidak memvalidasi apa pun yang dirilis.
- **Jaring pengaman yang tipis.** Hanya ada dua tes, tanpa CI, tanpa linter, tanpa pemeriksaan tipe. Tidak ada yang dapat mendeteksi regresi kecuali apa yang Anda tulis sendiri. Perlakukan rangkaian tes yang ada sebagai cakupan dasar yang tidak memadai, bukan sebagai gerbang.

### 6. Rencana implementasi (belum dilaksanakan)

1. **Tentukan semantik terlebih dahulu, secara tertulis.** Tipe prioritas (`int` vs enum), rentang yang valid, nilai default untuk pekerjaan yang sudah ada/belum ditentukan, dan arah penyortiran. Catat hal ini sebagai docstring pada `Job` di `scheduler/models.py` — itu adalah satu-satunya tempat yang sudah diandalkan oleh semua lapisan.
2. **Perluas model.** Tambahkan `priority: int = 0` sebagai bidang *terakhir* dari `Job` di `scheduler/models.py`, dengan tetap menjaga kompatibilitas posisi dengan `service.py:13` dan tidak mengubah `to_dict()`.
3. **Terapkan ke seluruh layanan.** Tambahkan parameter `priority` dengan nilai default ke `SchedulerService.create_job`, validasi parameter tersebut di samping pengecekan `name.strip()` yang sudah ada (lontarkan `ValueError`, sesuai dengan tipe kesalahan yang telah ditetapkan), dan serahkan ke konstruktor `Job`.
4. **Tentukan kontrak daftar secara eksplisit.** Opsi berisiko rendah yang disarankan: biarkan `JobRepository.all()` tetap sebagai primitif yang diurutkan berdasarkan `identifier`, dan tambahkan aksesor terpisah yang diurutkan berdasarkan prioritas. Jika sebaliknya `list_jobs()` harus mengubah maknanya, ubah komprehensi `JobRepository.all()` untuk mengurutkan nilai berdasarkan kunci gabungan eksplisit yang menyertakan `identifier` sebagai penentu jika terjadi seri, dan catat perubahan tersebut di `README.md`.
5. **Jaga agar `scheduler/__init__.py` tetap sinkron** hanya jika enum atau konstanta publik diperkenalkan.
6. **Jangan mengubah `scheduler/time_rules.py`**, dan jangan tambahkan berkas kecuali `expected_files` di `fixture-manifest.json` diperbarui dalam perubahan yang sama.

### 7. Rencana validasi

- **Lakukan baseline terlebih dahulu.** Jalankan `python3 -m unittest discover -s tests -v` sebelum melakukan pengeditan apa pun dan pastikan 2 tes lulus. Saya sudah melakukannya — hasilnya lulus tanpa masalah.
- **Pemeriksaan regresi.** Kedua tes yang ada harus tetap lulus tanpa dimodifikasi. Jika `test_create_and_list_jobs` perlu diedit, itu merupakan tanda bahwa perubahan tersebut menyebabkan kegagalan, bukan alasan untuk mengedit tes tersebut.
- **Kasus baru di `tests/test_scheduler.py`:**
  - Prioritas default saat `create_job` dipanggil dengan tanda tangan dua argumen lama (membuktikan kompatibilitas mundur).
  - Perjalanan bolak-balik prioritas secara eksplisit melalui `create_job` → `list_jobs`.
  - Pengurutan dengan **tiga atau lebih** prioritas yang berbeda, menguji daftar lengkap — inilah yang menentukan arah pengurutan.
  - Penentuan urutan saat seri: dua pekerjaan dengan prioritas sama akan dikembalikan berdasarkan urutan pengenal yang naik.
  - Prioritas yang tidak valid memicu `ValueError`, sama seperti kasus nama kosong.
  - `to_dict()` menyertakan `priority` dengan nilai yang diharapkan.
  - Jalur repositori yang disuntikkan: `SchedulerService(repository=fake)` tetap menetapkan prioritas dengan benar, menguji integrasi `repository or JobRepository()`.
- **Pemeriksaan kompatibilitas.** Pastikan semuanya berjalan di Python 3.9.6 secara spesifik — tanpa `slots=`, tanpa `kw_only=`, tanpa union PEP 604 tanpa penanda, tanpa `StrEnum`.
- **Pemeriksaan inventaris.** Baca kembali `fixture-manifest.json` dan pastikan kumpulan berkas di disk masih sesuai dengan `expected_files`.
- **Determinisme.** Jalankan rangkaian uji dua atau tiga kali; bug yang berkaitan dengan urutan iterasi kamus dapat muncul secara sporadis.
- **Kebersihan.** Jalankan dengan `PYTHONDONTWRITEBYTECODE=1` agar direktori `__pycache__` tidak muncul sebagai perubahan yang tidak terlacak terhadap manifest.

Hasil ini tidak mencerminkan kinerja pada monorepo berskala besar atau sesi otonom selama seminggu. Pengujian ini sengaja dirancang dalam skala kecil dan terkendali. Untuk evaluasi yang sesungguhnya, mulailah dengan prompt read-only: minta setiap alat untuk memetakan jalur panggilan, menyebutkan nama berkas yang akan diubah, mengidentifikasi tes, dan mencantumkan asumsi yang belum terselesaikan sebelum mengizinkan pengeditan.

Gaya implementasi, cakupan patch, dan perbaikan bug

Pekerjaan yang melibatkan banyak berkas

Perilaku kelulusan yang sama dapat berasal dari pilihan rekayasa yang berbeda. Pada T2, kedua produk memperoleh skor 30/30 dan lulus uji validator tersembunyi beku. Claude Code menempatkan validasi di lebih dari satu batas dan menambahkan uji model langsung serta uji ambang batas yang lebih luas. Codex menggunakan implementasi yang lebih kecil dan berpusat pada layanan, yang juga memenuhi kontrak.

Bagi seorang pengembang independen, ini merupakan dilema yang nyata. Validasi yang lebih luas dapat melindungi invarian saat objek dibuat melalui berbagai jalur. Patch yang lebih kecil dapat mengurangi risiko regresi dan mempersingkat waktu peninjauan jika satu layanan menjadi titik masuk yang dimaksudkan. Jawaban yang tepat bergantung pada aturan kepemilikan repositori, bukan pada penghitungan baris kode yang diubah atau tes secara terpisah.

Menambahkan prioritas pada model yang tidak dapat diubah, memvalidasi model tersebut di batas layanan, dan mempertahankan urutan di repositori.

Ketujuh tes publik dan validator tersembunyi yang dibekukan semuanya lulus.

Prioritas telah divalidasi baik pada batas layanan maupun model yang tidak dapat diubah, penyaringan repositori tetap dipertahankan, dan cakupan ambang batas telah ditambahkan.

Empat belas tes publik dan validator tersembunyi telah lulus.

Fitur prioritas tugas terjadwal telah diimplementasikan.

Berkas yang diubah:

- [scheduler/models.py](./scheduler/models.py:5) — ditambahkan `priority` yang diserialisasikan, dengan nilai default `0`.
- [scheduler/service.py](./scheduler/service.py:11) — ditambahkan validasi, penyimpanan, dan penyaringan `list_jobs(min_priority=0)` sambil mempertahankan urutan pengenal.
- [tests/test_scheduler.py](./tests/test_scheduler.py:16) — ditambahkan cakupan pengujian untuk nilai default, serialisasi, penyimpanan, batas, nilai yang tidak valid, dan penyaringan.

Pengujian dijalankan:

```text
python3 -m unittest discover -s tests -v
Menjalankan 7 pengujian — OK
```

**Kesimpulan:** Tugas yang dibekukan telah selesai dan diverifikasi.  
**Keputusan yang diperlukan:** Tidak ada.

Catatan Eksekusi # T2 — Fitur Prioritas Multi-Berkas

Parameter Eksekusi ##

| Kolom | Nilai |
| --- | --- |
| Tugas | `T2` |
| Prompt yang Dibekukan | `01-prompts/T2.md` |
| SHA-256 prompt beku | `8476a56034c4e719b97ee4081b32b4c73efd45feafe1bda9d477c83cb8fdb698` |
| Unit eksekusi | subagen Claude yang terisolasi, `general-purpose`, konteks baru |
| Metode isolasi | **fallback subagen** (penurunan versi yang terdokumentasi — lihat `results/isolation-decision.md`) |
| Salinan bersih yang ditugaskan | `runtime/workspaces/T2` |
| Versi kode Claude | `2.1.220` |
| Pengaturan model | `claude-opus-5` |
| start_utc | `2026-07-28T10:27:52Z` |
| end_utc | `2026-07-28T10:29:33Z` |
| Durasi | 101 detik (bersamaan dengan T1, T3, T4; bukan pengukuran latensi yang murni) |
| Nomor percobaan | 1 |
| Status | `valid` |
| Intervensi manusia | tidak ada |

## Ringkasan alat yang aman

`date`, `Baca`/`Edit`/`Tulis` hanya di dalam ruang kerja yang ditugaskan, `grep`,
`python3 -m unittest discover`, `python3 -m compileall`, pemeriksaan cepat `python3 -c` secara langsung.
Tanpa jaringan, tanpa instalasi, hanya pustaka standar.

## Berkas yang diubah

`scheduler/models.py`, `scheduler/repository.py`, `scheduler/service.py`,
`tests/test_scheduler.py`. Tidak ada berkas yang ditambahkan atau dihapus, sehingga `fixture-manifest.json` tetap
akurat. Patch lengkap: `results/T2/patch.diff`.

## Hasil pemeriksaan offline

Dilaporkan oleh pelaksana tugas:

| Pemeriksaan | Hasil |
| --- | --- |
| `python3 -m unittest discover -s tests -v` (baseline, sebelum perubahan) | 2 lulus, 0 gagal |
| `python3 -m compileall -q scheduler tests` | bersih |
| pemeriksaan smoke inline (konstruksi 3-arg lama, ambang batas kata kunci/posisi, `to_dict`) | lulus |
| `python3 -m unittest discover -s tests -v` (akhir) | **14 lulus, 0 gagal** |

Diverifikasi ulang secara independen oleh koordinator dari luar ruang kerja:

| Pemeriksaan | Keluar | Hasil |
| --- | --- | --- |
| rangkaian publik (`results/checks/T2-public.txt`) | 0 | 14 tes, OK |
| validator tersembunyi `03-checks/test_t2_hidden.py` (`results/checks/T2-hidden.txt`) | 0 | 2 tes, OK |

Validator tersembunyi gagal (keluar 1) saat diuji terhadap salinan fixture yang murni, yang menegaskan bahwa hasil lulus tersebut
memiliki arti. Lihat `results/checks/validator-controls.md`.

## Cakupan perilaku peta emas

Kelima perilaku yang diwajibkan dalam `03-checks/gold-map.json` terpenuhi:

| Perilaku yang diwajibkan | Bukti |
| --- | --- |
| prioritas default 0 | `Job.priority: int = MIN_PRIORITY`; `create_job(..., priority=MIN_PRIORITY)`; `test_priority_defaults_to_zero` |
| rentang bilangan bulat 0 hingga 9 | `validate_priority` menolak nilai non-bilangan bulat dan di luar rentang; `test_out_of_range_priority_is_rejected`, `test_non_integer_priority_is_rejected` |
| prioritas yang diserialisasikan | `to_dict()` melalui `asdict`; `test_priority_appears_in_serialized_output` memastikan kamus yang tepat |
| penyaringan prioritas minimum | `list_jobs(min_priority=0)` → `JobRepository.all(min_priority)`; `test_filter_is_inclusive_of_the_threshold` |
| urutan pengenal | filter diterapkan di dalam komprehensi `sorted(self._jobs)` yang sudah ada; `test_filter_preserves_ascending_identifier_order` |

## Kesalahan yang telah dibersihkan

Tidak ada. Artefak `__pycache__` dari eksekusi pengujian telah dihapus oleh pelaksana tugas; proses pembersihan koordinator
memastikan ruang kerja dalam keadaan bersih.

## Keluaran yang terlihat (verbatim)

Menambahkan bidang bilangan bulat `priority` ke pekerjaan yang dijadwalkan di seluruh lapisan model, repositori, dan layanan dari fixture penjadwal lokal, serta daftar yang difilter.

**`scheduler/models.py`** — Menambahkan konstanta modul `MIN_PRIORITY = 0` / `MAX_PRIORITY = 9` dan fungsi `validate_priority(priority)` yang dapat digunakan kembali, yang memicu `ValueError` untuk nilai non-bilangan bulat dan nilai di luar rentang 0–9 (termasuk 0 dan 9). `bool` secara eksplisit ditolak meskipun merupakan subkelas dari `int`, sehingga `True` tidak dapat lolos sebagai prioritas 1. Kelas data `Job` yang dibekukan mendapatkan `priority: int = MIN_PRIORITY` sebagai bidang penutup dengan nilai default, yang memastikan konstruksi dengan 3 argumen yang sudah ada tetap berfungsi, serta `__post_init__` yang memanggil validator sehingga prioritas yang tidak valid tidak dapat dibuat melalui jalur mana pun. `to_dict()` dibiarkan sebagai `asdict(self)`, sehingga prioritas muncul secara otomatis dalam keluaran serialisasi dan sesuai urutan bidang.

**`scheduler/repository.py`** — `JobRepository.all()` menerima argumen opsional `min_priority` dan melakukan penyaringan di dalam ekspresi pemrosesan `sorted(self._jobs)` yang sudah ada, sehingga urutan pengenal secara naik dijamin oleh jalur kode tunggal yang sama yang sudah menyediakannya, bukan ditetapkan ulang setelah penyaringan. Argumen default mempertahankan perilaku tanpa argumen sebelumnya untuk pemanggil yang sudah ada. Penyimpanan itu sendiri tidak memerlukan perubahan: repositori menyimpan instance `Job` secara utuh, sehingga prioritas tetap ada dan diteruskan melalui `save`/`get`/`all`.

**`scheduler/service.py`** — `create_job` menerima argumen `priority` opsional di bagian akhir (default 0) dan memvalidasinya sebelum membuat objek `Job`, sehingga kegagalan dilaporkan di batas layanan dengan kontrak `ValueError` yang sama seperti pemeriksaan nama kosong yang sudah ada. `list_jobs(min_priority=0)` mendelegasikan ke repositori. Pengurutan dan penyaringan berada di satu tempat, bukan diduplikasi.

**Catatan desain mengenai validasi `min_priority`:** nilainya diperiksa tipenya sebagai bilangan bulat, tetapi secara sengaja *tidak* dibatasi rentang ke 0–9. Aturan 0–9 membatasi apa yang dapat disimpan oleh sebuah pekerjaan; ambang batas adalah parameter kueri, dan menolak misalnya `min_priority=10` akan mengubah kueri "tidak cocok dengan apa pun" yang sah menjadi kesalahan. `list_jobs(min_priority=9)` yang mengembalikan `[]` ketika tidak ada pekerjaan dengan prioritas 9 telah diuji.

`scheduler/time_rules.py` telah dibaca tetapi tidak diubah — pergeseran waktu daylight saving yang didokumentasikan di dalamnya merupakan perilaku bawaan yang sudah ada sebelumnya, di luar cakupan tugas ini, dan mengubahnya akan menjadi perubahan perilaku yang tidak terkait. Tidak ada berkas yang ditambahkan atau dihapus, sehingga `fixture-manifest.json` tetap akurat (diverifikasi secara programatik).

### Menambahkan cakupan pengujian

Nilai default 0; proses bolak-balik penyimpanan melalui `JobRepository`; prioritas dalam keluaran `to_dict()`; nilai batas 0 dan 9 diterima; nilai di luar rentang −1/10/100 ditolak; nilai non-bilangan bulat `"3"`/`3.5`/`None`/`True` ditolak; validasi langsung di tingkat model; urutan daftar tanpa penyaringan; daftar yang disaring dengan tetap mempertahankan urutan pengenal secara naik; ambang batas inklusif; hasil kosong; nilai `min_priority` non-bilangan bulat ditolak.

Perbaikan bug pada kasus-kasus khusus

T3 menguji adanya cacat dalam penjadwalan terkait waktu musim panas. Kedua agen memperoleh skor 30/30 dan lulus pemeriksaan tersembunyi yang sama pada musim semi dan musim gugur. Kode Claude menambahkan cakupan eksplisit untuk waktu lokal yang ambigu dan terlewatkan, masukan yang naif, serta pengulangan selama beberapa hari. Codex melakukan perubahan hari kalender yang lebih terbatas dan lulus kontrak beku.

Pengujian kasus tepi yang lebih luas akan meningkatkan keyakinan ketika pustaka tersebut digunakan kembali secara luas atau ketika konsekuensi dari kesalahan penjadwalan sangat besar. Perubahan yang terbatas menjadi pilihan yang menarik ketika cacat sudah terisolasi dengan baik dan tim ingin meminimalkan perubahan perilaku. Pertanyaan tinjauan praktisnya bukanlah “Siapa yang menulis lebih banyak?” Melainkan apakah tambalan tersebut memperbaiki akar masalah yang disebutkan, mempertahankan kontrak di sekitarnya, dan membuktikan batas-batas yang berisiko.

Penyebab utama: implementasi tersebut menambah 24 jam UTC yang telah berlalu.

Perbaikan: memajukan tanggal satu hari kalender lokal. Kedua pemeriksaan musim semi dan musim gugur yang dibekukan berhasil dilalui.

Telah mencakup musim semi dan musim gugur, waktu lokal yang terlewatkan dan ambigu, input yang tidak tervalidasi, serta perulangan selama beberapa hari.

Kedua pemeriksaan tersembunyi yang dibekukan telah lulus setelah cakupan regresi yang lebih luas.

Perbaikan DST telah diterapkan.

Berkas yang diubah:

- [scheduler/time_rules.py](./scheduler/time_rules.py)
- [tests/test_time_rules.py](./tests/test_time_rules.py)

Perubahan:

- Menggeser waktu satu hari kalender lokal, bukan 24 jam UTC.
- Menambahkan uji regresi untuk penyesuaian waktu musim semi dan musim gugur di New York.
- Memverifikasi bahwa interval waktu yang berlalu dalam UTC masing-masing adalah 23 dan 25 jam.

Pemeriksaan:

- Uji unit: 4 lulus.
- Pemeriksaan sintaks dalam memori: 7 berkas Python lulus.
- Kompilasi bytecode terhambat karena Python mengalihkan cache-nya ke luar ruang kerja yang ditetapkan; tidak ada berkas eksternal yang ditulis.

**Kesimpulan:** `next_daily_run` kini mempertahankan jam jam dinding yang diminta selama transisi DST. Tidak diperlukan keputusan.

Catatan Eksekusi # T3 — Perbaikan Bug DST

Parameter Eksekusi ##

| Kolom | Nilai |
| --- | --- |
| Tugas | `T3` |
| Prompt yang dibekukan | `01-prompts/T3.md` |
| SHA-256 prompt beku | `3fee50d0230f27f8d6dd7f12e050fa3f0b7f5fb77d9559361fee96e5f1a47307` |
| Unit eksekusi | subagen Claude yang terisolasi, `general-purpose`, konteks baru |
| Metode isolasi | **fallback subagen** (penurunan versi yang terdokumentasi — lihat `results/isolation-decision.md`) |
| Salinan bersih yang ditugaskan | `runtime/workspaces/T3` |
| Versi kode Claude | `2.1.220` |
| Pengaturan model | `claude-opus-5` |
| start_utc | `2026-07-28T10:28:05Z` |
| end_utc | `2026-07-28T10:30:03Z` |
| Durasi | 118 detik (bersamaan dengan T1, T2, T4; bukan pengukuran latensi yang murni) |
| Nomor percobaan | 1 |
| Status | `valid` |
| Intervensi manusia | tidak ada |

## Ringkasan alat yang aman

`date`, `Baca`/`Edit` hanya di dalam ruang kerja yang ditetapkan, `python3 -m unittest discover`,
`python3 -m compileall`, eksekusi kontrol negatif dalam memori, pemeriksaan integritas manifest.
Hanya pustaka standar (`datetime`, `zoneinfo`, `unittest`). Tanpa jaringan, tanpa instalasi.

## Berkas yang diubah

`scheduler/time_rules.py` (perbaikan — hanya isi dan docstring dari `next_daily_run`),
`tests/test_scheduler.py` (ditambahkan `NextDailyRunTests`, 8 tes, ditambah helper `_elapsed`;
tes yang sudah ada tidak diubah). Tidak ada modul lain yang diubah, tidak ada berkas yang ditambahkan. Patch lengkap:
`results/T3/patch.diff`.

## Hasil pemeriksaan offline

Dilaporkan oleh pelaksana tugas:

| Pemeriksaan | Hasil |
| --- | --- |
| `python3 -m unittest discover -s tests -v` | **10 lulus, 0 gagal** (2 yang sudah ada + 8 baru) |
| `python3 -m compileall -q scheduler tests` | bersih |
| integritas manifest vs `fixture-manifest.json` | 0 hilang, 0 tidak terduga |
| kontrol negatif: implementasi yang telah di-seed ditambal dalam memori, hanya `NextDailyRunTests` | 8 dijalankan, **5 gagal sesuai rencana**, termasuk kedua tes DST |

Diverifikasi ulang secara independen oleh koordinator dari luar ruang kerja:

| Pemeriksaan | Keluar | Hasil |
| --- | --- | --- |
| rangkaian publik (`results/checks/T3-public.txt`) | 0 | 10 tes, OK |
| validator tersembunyi `03-checks/test_t3_hidden.py` (`results/checks/T3-hidden.txt`) | 0 | 2 tes, OK |

Validator tersembunyi gagal (keluar 1) saat diuji terhadap salinan fixture yang murni. Lihat
`results/checks/validator-controls.md`.

## Cakupan perilaku peta emas

Keempat perilaku yang diwajibkan dalam `03-checks/gold-map.json` terpenuhi:

| Perilaku yang diwajibkan | Bukti |
| --- | --- |
| jam jam dinding dipertahankan | penambahan diterapkan pada jam dinding lokal yang sederhana, zona dihubungkan kembali; diverifikasi dalam setiap uji DST |
| transisi musim semi tercakup | `test_spring_forward_keeps_requested_hour` — jam 09:30 dipertahankan, offset `-04:00`, waktu yang berlalu 23 jam |
| transisi musim gugur tercakup | `test_fall_back_keeps_requested_hour` — jam 09:30 dipertahankan, offset `-05:00`, waktu yang berlalu 25 jam |
| zona waktu IANA digunakan | `ZoneInfo("America/New_York")` dari pustaka standar |

Selain rangkaian yang diwajibkan, pelaksana uji juga mencakup dua kasus tepi PEP 495 — waktu dinding
yang dilewati oleh spring-forward dan waktu dinding yang ambigu selama fall-back — ditambah perulangan tujuh hari
yang mencakup setiap transisi serta perilaku input naif.

## Kesalahan yang telah diperbaiki

Dua kegagalan asersi pengujian yang disebabkan sendiri: `following - previous` pada dua objek datetime yang berbagi
`tzinfo` mengurangkan waktu dinding naif, sehingga asersi waktu yang berlalu menunjukkan 1 hari dan gagal.
Implementasinya benar dan asersi tersebut salah; diperbaiki dengan helper `_elapsed`
yang mengonversi kedua operand ke UTC terlebih dahulu. Tidak ada kesalahan alat, impor, atau lingkungan.
Artefak `__pycache__` dihapus setelah eksekusi.

## Keluaran yang terlihat (secara harfiah)

**Reproduksi**

`scheduler/time_rules.py::next_daily_run` dipanggil dengan datetime `America/New_York` di kedua sisi transisi DST tahun 2024:

```
2024-03-09T09:30:00-05:00 -> 2024-03-10T10:30:00-04:00   # jam bergeser +1
2024-11-02T09:30:00-04:00 -> 2024-11-03T08:30:00-05:00   # jam bergeser -1
```

Sebuah pekerjaan yang dijadwalkan pada pukul 09:30 waktu setempat dijalankan pada pukul 10:30 setelah penyesuaian waktu musim semi dan pukul 08:30 setelah penyesuaian waktu musim gugur.

**Penyebab utama**

Implementasi yang disediakan menganggap "daily" sebagai durasi absolut yang tetap:

```python
elapsed = previous_run.astimezone(timezone.utc) + timedelta(hours=24)
return elapsed.astimezone(previous_run.tzinfo)
```

Konversi ke UTC terlebih dahulu membuat `timedelta(hours=24)` menjadi tepat 24 jam yang telah berlalu. Namun, satu hari kalender lokal di zona IANA berdurasi 23 jam pada hari penyesuaian waktu ke depan (spring-forward) dan 25 jam pada hari penyesuaian waktu ke belakang (fall-back), sehingga offset konstan sebesar 24 jam pasti akan menghasilkan selisih satu jam dari waktu jam dinding yang diminta.

**Solusinya** (`scheduler/time_rules.py`)

Pengulangan harian merupakan aturan kalender, sehingga penambahan waktu kini diterapkan pada jam dinding lokal yang belum disesuaikan zona waktu, dengan zona waktu ditambahkan kembali setelahnya:

```python
tzinfo = previous_run.tzinfo
naive_next = previous_run.replace(tzinfo=None) + timedelta(days=1)
if tzinfo is None:
    return naive_next
candidate = naive_next.replace(tzinfo=tzinfo, fold=0)
return candidate.astimezone(timezone.utc).astimezone(tzinfo)
```

Mengapa ini benar:
- Perhitungan jam dinding pada nilai naif tidak bergantung pada offset, sehingga nilai jam:menit yang diminta tetap terjaga secara otomatis; `zoneinfo` kemudian menyediakan offset UTC mana pun yang berlaku pada tanggal baru (terverifikasi: `-04:00` setelah penyesuaian waktu musim semi, `-05:00` setelah penyesuaian waktu musim gugur, dengan waktu nyata yang berlalu masing-masing 23 jam dan 25 jam).
- `fold=0` ditambah perhitungan bolak-balik UTC menangani dua kasus tepi yang tidak terdefinisi dengan jelas oleh perhitungan waktu jam dinding murni. Berdasarkan PEP 495, waktu jam dinding yang *dilewati* (02:30 pada 2024-03-10) memiliki offset pra-transisi pada `fold=0`, sehingga perhitungan bolak-balik menormalkannya ke saat nyata 03:30 EDT, bukan mengembalikan datetime yang tidak merujuk pada saat tertentu. Waktu jam dinding yang *ambigu* (01:30 pada 2024-11-03) diselesaikan secara deterministik ke kemunculan pertamanya (EDT) alih-alih menjadi sembarangan.
- Masukan sederhana tetap mempertahankan arti sebelumnya (penambahan 1 hari kalender biasa) — tidak ada persyaratan `tzinfo` baru yang diberlakukan pada pemanggil.

Cakupan perubahan dijaga tetap sempit: hanya isi/docstring dari `next_daily_run` yang diubah. `service.py`, `models.py`, `repository.py`, dan `__init__.py` tidak diubah, tidak ada berkas baru yang ditambahkan, dan manifes fixture masih cocok persis (tidak ada berkas yang hilang atau tidak terduga). Hanya menggunakan pustaka standar (`datetime`, `zoneinfo`, `unittest`).

**Uji regresi** (`tests/test_scheduler.py`, `NextDailyRunTests` yang baru, 8 tes) mencakup: stabilitas pada hari biasa, pergeseran waktu musim semi (jam + offset + 23 jam berlalu), pergeseran waktu musim gugur (jam + offset + 25 jam berlalu), siklus tujuh hari yang mencakup setiap transisi, waktu dinding yang dilewati, waktu dinding yang ambigu, dan masukan naif.

Ada dua catatan yang perlu dicatat. Pertama, asersi waktu yang telah berlalu awalnya menggunakan `following - previous`; Python mengabaikan `tzinfo` yang sama dan mengurangkan jam dinding naif, sehingga keduanya mengembalikan 1 hari dan gagal. Implementasinya benar dan asersi tersebut salah — diperbaiki dengan helper `_elapsed` yang mengonversi kedua operand ke UTC. Kedua, saya memverifikasi bahwa tes tersebut benar-benar mendeteksi cacat asli dengan menjalankan ulang `NextDailyRunTests` terhadap salinan dalam memori dari implementasi yang telah diberi benih: 5 dari 8 gagal, termasuk kedua tes DST. Tiga tes yang lulus pada versi yang bermasalah (hari biasa, dilewati, ambigu) lebih berfungsi sebagai dokumentasi perilaku daripada mendeteksi regresi — kasus dilewati/ambigu kebetulan cocok karena pergeseran absolut +24 jam kebetulan jatuh pada saat yang sama dalam skala normalisasi.

Kualitas tinjauan kode dan verifikasi oleh manusia

Tugas peninjauan kode menguji keterampilan yang berbeda dari implementasi fitur. Seorang peninjau yang kompeten harus dapat menemukan masalah yang dapat direproduksi, menilai tingkat dampaknya, menyebutkan jalur kode yang tepat, serta membedakan antara cacat yang nyata dengan peringatan yang bersifat spekulatif. Memperbaiki suatu masalah menambah satu uji lagi: tambalan (patch) tersebut tidak boleh menimbulkan regresi baru.

Kode Claude menunjukkan keunggulan paling jelas pada T4. Codex melaporkan lima temuan yang dapat direproduksi secara independen, termasuk kedua target tinjauan yang disisipkan, dan memperoleh skor 19/20. Codex melaporkan dan memperbaiki dua cacat valid dengan tingkat keparahan lebih tinggi, tetapi tidak menyebutkan pasangan yang disisipkan, sehingga memperoleh skor 18/20. Temuan Codex bukanlah false positive; perbedaan yang diamati terletak pada cakupan, bukan pada kebenaran dasar.

1. Tinggi — Pekerjaan yang sudah ada berpotensi ditimpa tanpa pemberitahuan.

2. Sedang — Eksekusi harian mengalami penyimpangan saat peralihan waktu musim panas.

Verifikasi: empat tes berhasil, tidak ada kegagalan.

D1 Pergeseran DST · Tinggi
D2 Pengambilan zona waktu secara naif · Sedang
D3 Tabrakan pengenal · Tinggi
D4 Penghapusan yang terlewat memicu KeyError · Sedang
D5 Pemilik tidak diverifikasi · Rendah

## Temuan yang Perlu Ditindaklanjuti

1. **Tinggi — Pekerjaan yang sudah ada berpotensi ditimpa tanpa pemberitahuan**

   - Bukti: inisialisasi pengenal di [service.py](./scheduler/service.py:8), dikombinasikan dengan penggantian kamus di [repository.py](./scheduler/repository.py:9).
   - Dampak: membuat layanan dengan repositori yang sudah ada dapat menggunakan kembali pengenal `1`, menggantikan pekerjaan yang tersimpan, dan menyebabkan kehilangan data.
   - Reproduksi minimal: simpan `Job(1, ...)`, buat `SchedulerService(repository)`, lalu buat pekerjaan lain. Sebelum diperbaiki, hanya pekerjaan baru yang tersisa.
   - Perbaikan: inisialisasi pengenal berikutnya dari pengenal tertinggi yang sudah ada di repositori.
   - Uji regresi: [test_scheduler.py](./tests/test_scheduler.py:22).

2. **Sedang — Jadwal harian bergeser saat transisi waktu musim panas**

   - Bukti: perhitungan yang telah diperbaiki di [time_rules.py](./scheduler/time_rules.py:4).
   - Dampak: pekerjaan harian yang dijadwalkan pukul 09:00 berjalan pada pukul 10:00 setelah peralihan Waktu Musim Panas (DST) musim semi.
   - Reproduksi minimal: hitung jadwal eksekusi berikutnya setelah `2026-03-07 09:00 America/New_York`. Sebelum perbaikan, hasilnya adalah `2026-03-08 10:00`.
   - Perbaikan: tambahkan satu hari kalender lokal alih-alih 24 jam UTC yang telah berlalu.
   - Uji regresi: [test_scheduler.py](./tests/test_scheduler.py:33).

## Berkas yang diubah

- [scheduler/service.py](./scheduler/service.py)
- [scheduler/time_rules.py](./scheduler/time_rules.py)
- [tests/test_scheduler.py](./tests/test_scheduler.py)

## Verifikasi

- Kedua uji regresi tersebut terdeteksi gagal sebelum diperbaiki.
- Masing-masing lulus setelah perbaikan yang sesuai.
- `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -v`
- Hasil: **4 uji lulus, 0 kegagalan**.
- Tidak ada artefak cache Python yang dihasilkan yang tersisa.

## Kesimpulan dan keputusan

- **Kesimpulan:** Kedua cacat yang dikonfirmasi telah diperbaiki dan tercakup oleh uji regresi yang difokuskan.
- **Keputusan yang diperlukan:** Tidak ada.

Catatan Pelaksanaan # T4 — Uji Coba dan Tinjauan Kode

Parameter Pelaksanaan ##

| Kolom | Nilai |
| --- | --- |
| Tugas | `T4` |
| Prompt yang dibekukan | `01-prompts/T4.md` |
| SHA-256 prompt beku | `5e69546007ea776f40b3d334ddb75671ff684c151c77551bad27de3b0fdce640` |
| Unit eksekusi | subagen Claude yang terisolasi, `general-purpose`, konteks baru |
| Metode isolasi | **fallback subagen** (penurunan versi yang terdokumentasi — lihat `results/isolation-decision.md`) |
| Salinan bersih yang ditugaskan | `runtime/workspaces/T4` |
| Versi kode Claude | `2.1.220` |
| Pengaturan model | `claude-opus-5` |
| start_utc | `2026-07-28T10:28:22Z` |
| end_utc | `2026-07-28T10:32:17Z` |
| Durasi | 235 detik (bersamaan dengan T1–T3; bukan pengukuran latensi yang murni) |
| Nomor percobaan | 1 |
| Status | `valid` |
| Intervensi manusia | tidak ada |

Kondisi dalam prompt yang dibekukan — "perbaiki jika konfigurasi eksekusi yang dibekukan mengizinkan
perbaikan" — diselesaikan oleh koordinator dari `00-control/run-config.json` dan
`00-control/safety-policy.json`, yang mengizinkan penulisan salinan fixture yang terisolasi. Pelaksana (runner)
diberitahu bahwa perbaikan diperbolehkan. Ia tidak diperlihatkan berkas kontrol apa pun.

## Ringkasan alat yang aman

`date`, `Baca`/`Edit`/`Tulis` hanya di dalam ruang kerja yang ditugaskan, `grep`,
`python3 -m unittest discover`, `python3 -m compileall`, eksekusi kosong pada salinan sementara,
pemeriksaan keberadaan manifes. Tanpa jaringan, tanpa instalasi, hanya pustaka standar.

## Berkas yang diubah

`scheduler/time_rules.py` (diubah), `scheduler/service.py` (diubah),
`tests/test_scheduler.py` (diubah, +2 tes), `tests/test_time_rules.py` (ditambahkan, 5 tes).
Patch lengkap: `results/T4/patch.diff`.

## Hasil pemeriksaan offline

Dilaporkan oleh pelaksana tugas:

| Pemeriksaan | Hasil |
| --- | --- |
| `python3 -m unittest discover -s tests -v` | **9 lulus, 0 gagal, 0 dilewati** (baseline 2) |
| `python3 -m compileall -q scheduler tests` | lulus |
| pemeriksaan keberadaan manifest vs `expected_files` | semua 8 ada |
| eksekusi vacuity terhadap implementasi asli yang dipulihkan | 5 gagal, 4 lulus, sesuai harapan |

Diverifikasi ulang secara independen oleh koordinator dari luar ruang kerja:

| Pemeriksaan | Keluaran | Hasil |
| --- | --- | --- |
| rangkaian uji publik (`results/checks/T4-public.txt`) | 0 | 9 uji, OK |

Pemeriksaan silang informasional, tidak dinilai: validator tersembunyi T3 juga lulus terhadap ruang kerja ini
(keluar 0), karena T4 secara independen memperbaiki cacat `next_daily_run` yang sama. Lihat
`results/checks/validator-controls.md`.

## Cakupan cacat peta emas

`03-checks/gold-map.json` menanam dua cacat untuk penilaian T4. Keduanya ditemukan:

| Cacat yang ditanam | Ditemukan | Dilaporkan sebagai |
| --- | --- | --- |
| pemilik kosong diterima | ya | **D5**, `scheduler/service.py:11,13`, tingkat keparahan Rendah, dilaporkan dan sengaja tidak diperbaiki |
| penghapusan pengenal yang hilang memicu `KeyError` | ya | **D4**, `scheduler/repository.py:19` → `service.py:22`, tingkat keparahan Sedang, dilaporkan dan sengaja tidak diperbaiki |

Tiga temuan tambahan dilaporkan di luar kumpulan yang disisipkan. Tidak ada yang merupakan hasil positif palsu:

- **D1** — Pergeseran DST di `next_daily_run`. Ini adalah cacat ketiga yang tercantum dalam
  `03-checks/seeded-defects.md` (dinilai di bawah T3, bukan T4, tetapi ini adalah bug yang benar-benar disengaja).
- **D2** — masukan yang naif ke `next_daily_run` secara diam-diam mengambil zona waktu host dan mengembalikan
  datetime yang sesuai. Nyata dan bergantung pada host; diverifikasi oleh koordinator berdasarkan sumber fixture.
- **D3** — tabrakan pengenal antara layanan dan repositori yang disuntikkan atau dibagikan, yang menyebabkan
  penimpaan diam-diam. Nyata: `SchedulerService._next_identifier` selalu dimulai dari 1 sementara
  `JobRepository.save` merupakan penugasan kamus yang tidak dilindungi. T1 secara independen mengidentifikasi
  celah yang sama dari fixture yang masih murni.

Jumlah false-positive: **0**. Runner juga melaporkan dengan benar bahwa tidak ada temuan keamanan, dengan catatan
bahwa fixture tersebut tidak memiliki permukaan jaringan, I/O, deserialisasi, subproses, atau kredensial.

## Penyimpangan yang layak dicatat

Prompt yang dibekukan meminta pengujian dan perbaikan pada "dua cacat dengan tingkat keyakinan tertinggi".
Runner memilih D1/D2 (satu perbaikan, fungsi yang sama) dan D3, alih-alih dua cacat yang disematkan dalam peta acuan
yaitu D4 dan D5. Alasan yang dikemukakan dapat dibenarkan: D4 dan D5 keduanya bergantung pada kontrak API
yang tidak ditentukan, sehingga memperbaikinya hanya akan menjadi tebakan. Kredit deteksi tidak terpengaruh — kedua cacat yang disematkan
telah ditemukan, lengkap dengan file, baris, tingkat keparahan, dampak, dan reproduksi. Perbaikan yang diterapkan ditujukan pada
cacat yang sebenarnya dan didukung oleh pemeriksaan kekosongan.

## Kesalahan yang telah disanitasi

Dua kegagalan pengujian yang disebabkan sendiri akibat pengurangan waktu jam dinding versus waktu absolut pada tanggal-waktu
yang berbagi `tzinfo`; telah diperbaiki dan diverifikasi ulang. Tidak ada kesalahan alat atau lingkungan. Artefak `__pycache__`
telah dihapus setelah proses berjalan.

## Keluaran yang terlihat (verbatim)

### Laporan cacat

**D1 — `scheduler/time_rules.py:10-11` — Jadwal harian bergeser satu jam selama DST — Tingkat Keparahan: Tinggi**

`next_daily_run` menambahkan 24 jam *yang telah berlalu* melalui perjalanan bolak-balik UTC alih-alih memajukan hari kalender. Sebuah tugas harian ditentukan berdasarkan waktu jam dinding, sehingga setiap tugas di zona yang menerapkan DST secara diam-diam dijalankan satu jam lebih awal atau lebih lambat mulai dari hari peralihan ke depan, dan kesalahan ini terus berlanjut (setiap eksekusi memulai ulang dari waktu yang bergeser). Docstring itu sendiri mengakui perilaku tersebut.

```
prev = datetime(2024, 3, 9, 9, 0, tzinfo=ZoneInfo("America/New_York"))
next_daily_run(prev)   # -> 2024-03-10 10:00:00-04:00, diharapkan 09:00-04:00
prev = datetime(2024, 11, 2, 9, 0, tzinfo=ZoneInfo("America/New_York"))
next_daily_run(prev)   # -> 2024-11-03 08:00:00-05:00, diharapkan 09:00-05:00
```

**D2 — `scheduler/time_rules.py:10-11` — Masukan yang tidak terverifikasi secara diam-diam menggunakan zona waktu lokal mesin — Tingkat Keparahan: Sedang**

Dua baris yang sama. `.astimezone(timezone.utc)` pada datetime naif mengasumsikan waktu lokal sistem, dan `.astimezone(None)` mengembalikan datetime yang sadar zona waktu. Panggilan dengan masukan `naive` mengembalikan hasil `aware`, sehingga hasilnya tidak dapat dibandingkan dengan nilai `naive` lainnya dari pemanggil (`TypeError` saat perbandingan) dan hasilnya bergantung pada `TZ` host.

```
next_daily_run(datetime(2024, 1, 1, 9, 0))
# -> datetime(2024, 1, 2, 9, 0, tzinfo=timezone(timedelta(hours=8), 'CST'))  # bergantung pada host
```

**D3 — `scheduler/service.py:8,13,15` (pre-fix) — Tabrakan pengenal secara diam-diam menghancurkan pekerjaan yang tersimpan — Tingkat Keparahan: Tinggi**

Penghitung ID dilakukan per `SchedulerService` dan selalu dimulai dari 1, mengabaikan isi repositori yang disuntikkan. Layanan kedua apa pun yang menggunakan repositori bersama, atau layanan apa pun yang menggunakan repositori yang telah diisi sebelumnya, akan menerbitkan ulang ID 1; `JobRepository.save` adalah penugasan kamus, sehingga pekerjaan yang sudah ada ditimpa tanpa kesalahan. Kehilangan data.

```
repo = JobRepository()
SchedulerService(repo).create_job("Nightly backup", "Alex")    # id 1
SchedulerService(repo).create_job("Payroll export", "Blake")   # id 1 lagi
repo.all()   # -> [Job(1, 'Payroll export', 'Blake')]  — Pekerjaan Alex hilang
```

**D4 — `scheduler/repository.py:19` → `scheduler/service.py:22` — `delete_job` memicu `KeyError` karena id yang tidak dikenal — Tingkat Keparahan: Sedang**

`delete` menggunakan `dict.pop` tanpa nilai default, sedangkan metode saudara `get` (baris 13) mengembalikan `None` jika tidak ditemukan. Ketidakkonsistenan ini menyebabkan `KeyError` mentah bocor melalui `SchedulerService.delete_job`, yang kemungkinan besar tidak akan ditangkap oleh pemanggil. Contoh: `SchedulerService().delete_job(999)` → `KeyError: 999`. Perbaikan yang mungkin adalah `pop(identifier, None)` atau pengecualian domain eksplisit — sengaja tidak diperbaiki, karena kontrak yang benar (tidak ada operasi tanpa pemberitahuan vs. kesalahan bertipe) merupakan keputusan API yang menjadi kewenangan pemilik.

**D5 — `scheduler/service.py:11,13` — Bidang `owner` tidak diverifikasi — Tingkat Keparahan: Rendah**

`name` diperiksa apakah kosong, tetapi `owner` tidak: `create_job("ok", "   ")` menyimpan `owner=''`. Kedua parameter tersebut juga memanggil `.strip()` tanpa perlindungan, sehingga `None` muncul sebagai `AttributeError: 'NoneType' object has no attribute 'strip'`, bukan `ValueError` yang biasanya digunakan API untuk input yang salah. Dibiarkan tanpa perbaikan — kontrak `owner` yang dimaksud tidak disebutkan di mana pun dalam fixture.

**Keamanan:** tidak ada temuan. Fixture ini tidak memiliki permukaan jaringan, I/O, deserialisasi, subproses, atau kredensial; penyimpanan berupa kamus (dict) dalam proses.

**Kesenjangan cakupan:** `scheduler/time_rules.py` dan `scheduler/repository.py` memiliki cakupan pengujian nol sebelum eksekusi ini; kedua pengujian yang disiapkan hanya menguji jalur normal layanan.

### Pengujian dan perbaikan yang diterapkan

Dua cacat dengan tingkat keyakinan tertinggi adalah **D1/D2** (fungsi yang sama, satu perbaikan) dan **D3**.

**Perbaikan 1 — `scheduler/time_rules.py`:** mengganti perhitungan bolak-balik UTC dengan `previous_run + timedelta(days=1)`. Python melakukan perhitungan waktu jam dinding pada datetime yang sadar zona waktu, dan `zoneinfo` menghitung ulang offset UTC secara malas dari waktu jam dinding yang baru — sehingga 09:00 tetap 09:00 sementara offset bergerak dengan benar dari `-05:00 → -04:00`. Hal ini memperbaiki D1 dan D2 sekaligus: input naif kini tetap naif dan zona lokal tidak pernah disimpulkan. Kasus peralihan jam antara "tidak dapat dijangkau" dan "ambigu" didokumentasikan sebagai mengikuti aturan pengelompokan (fold rules) dari `tzinfo`.

**Perbaikan 2 — `scheduler/service.py`:** penghapusan penghitung `_next_identifier` per-instansi; pengenal kini dialokasikan dari status repositori sebagai `max(pengenal yang ada, default=0) + 1` pada saat pembuatan. Hal ini benar baik untuk repositori bersama maupun yang telah diisi sebelumnya. Kompromi: O(n) per pembuatan alih-alih O(1), dapat diterima untuk penyimpanan dalam memori yang didukung kamus, dan keakuratan dibandingkan penghitung yang tidak dapat melihat penyimpanan tempatnya menulis.

**Pengujian — `tests/test_time_rules.py` (baru, 5 pengujian):** pelestarian waktu jam dinding saat spring-forward dan fall-back, waktu absolut yang berlalu sebesar 23 jam/25 jam selama transisi tersebut, resolusi ulang offset UTC, prinsip "naive-stays-naive", dan pergeseran hari UTC biasa. Akan dilewati dengan lancar jika basis data IANA tidak tersedia.

**Pengujian — `tests/test_scheduler.py` (diperluas, +2 pengujian):** dua layanan yang berbagi satu repositori harus mengeluarkan ID yang berbeda dan mempertahankan kedua pekerjaan; layanan yang mengakses repositori yang telah diisi sebelumnya dengan ID 1 dan 7 harus mengeluarkan ID 8 dan membiarkan pekerjaan yang ada tetap utuh.

**Pemeriksaan kelemahan:** Saya memulihkan kedua implementasi asli dalam salinan sementara dan menjalankan kembali rangkaian uji — kelima uji baru gagal (`FAILED (failures=5)`), dan semuanya lulus saat dijalankan pada kode yang telah diperbaiki. Uji-uji tersebut benar-benar mengidentifikasi cacat tersebut.

Satu koreksi selama proses pengujian: draf pertama saya mengasumsikan waktu DST yang telah berlalu sebagai `result - previous`, yang dievaluasi Python sebagai aritmatika waktu jam dinding ketika kedua operand berbagi tzinfo, sehingga hasilnya menjadi `24h` dan tes gagal. Asersi tersebut kini dikonversi ke UTC sebelum dikurangkan. Kegagalan tersebut terjadi pada tes saya, bukan pada perbaikan kode.

### Catatan untuk pemilik

`fixture-manifest.json` tidak diubah, sehingga `tests/test_time_rules.py` adalah berkas baru yang sah yang tidak tercantum dalam `expected_files` — perbarui manifes jika pemeriksaan mengharuskan kumpulan berkas yang tepat. Selain itu, D4/D5 telah dilaporkan tetapi sengaja tidak diperbaiki: keduanya bergantung pada keputusan kontrak API (semantik "miss-on-delete", aturan validasi pemilik) yang tidak ditentukan di mana pun dalam fixture, sehingga memilih salah satunya hanyalah tebakan, bukan perbaikan.

Kedua skor tersebut tidak menghilangkan kebutuhan akan peninjauan oleh manusia. Setelah salah satu agen menyelesaikan proses perbaikan, periksa antarmuka yang telah diubah, cakupan berkas yang tidak terduga, uji negatif yang terlewat, riwayat izin atau perintah, serta jalur rollback. Penjelasan yang meyakinkan tidak dapat menggantikan uji yang dapat direproduksi.

Izin, sandboxing, dan keamanan operasional

Seorang agen pemrograman dapat membaca kode pribadi, menjalankan perintah shell, mengubah banyak berkas, dan memanggil alat eksternal. Hal itu menjadikan desain izin sebagai bagian dari kualitas produk. Pertanyaan-pertanyaan yang relevan adalah: operasi mana saja yang memerlukan persetujuan, apa saja yang dapat diakses agen secara default, seberapa jelas agen tersebut menampilkan pratinjau tindakan berisiko, dan apakah seorang pengembang dapat memeriksa perubahan yang dihasilkan.

Jangan menganggap bahwa semakin sedikit permintaan persetujuan berarti otomatis lebih baik. Proses yang lancar memang berguna dalam lingkungan terisolasi yang tidak melibatkan kredensial atau koneksi ke lingkungan produksi. Namun, perilaku yang sama bisa berbahaya dalam repositori yang terhubung ke skrip deployment, data pelanggan yang sebenarnya, atau izin cloud yang luas. Sebaliknya, permintaan persetujuan yang berlebihan dapat membuat otomatisasi yang aman menjadi tidak praktis dan mendorong pengguna untuk menyetujui permintaan tanpa membacanya terlebih dahulu.

Pengujian kami menggunakan salinan lokal yang baru, tanpa melibatkan sistem produksi, tanpa proses penerapan, dan tanpa campur tangan manusia yang memengaruhi hasil pengujian. Oleh karena itu, pengujian ini mengevaluasi penyelesaian tugas dalam kondisi yang aman, bukan tingkat keamanan relatif dari kedua produk tersebut. Sebelum menggunakan salah satu alat ini untuk pekerjaan penting, mulailah dengan akses baca-saja, tentukan direktori dan perintah yang diizinkan, tinjau perbedaan (diff), dan jalankan pemeriksaan objektif dalam lingkungan yang dapat dipulihkan.

• Mulailah dengan arsitektur read-only atau ambil risiko.
• Setujui hanya perintah yang ruang lingkup dan konsekuensinya Anda pahami.
• Simpan kredensial, data produksi, dan akses penyebaran di luar lingkungan uji coba.
• Pastikan terdapat file diff, serangkaian uji coba, dan jalur rollback yang jelas sebelum menerima hasilnya.

MCP, Keterampilan, petunjuk proyek, dan penyesuaian

Kedua ekosistem tersebut dapat diperluas, namun istilah-istilah perluasan tersebut tidak boleh dianggap sebagai sinonim. Petunjuk proyek memberi tahu seorang agen bagaimana berperilaku di dalam repositori. Keterampilan yang Dapat Digunakan Kembali (Reusable Skills) mengemas alur kerja atau keahlian yang dapat diulang. MCP menghubungkan host ke alat atau data eksternal. Hooks dan perintah dapat mengotomatiskan momen-momen tertentu dalam siklus pengembangan. Sebuah produk dapat unggul di satu lapisan tanpa harus menyamai fitur di lapisan lain secara persis.

Pertanyaan utama dalam pembelian bukanlah apakah logo integrasi itu ada. Melainkan apakah koneksi tersebut dapat dipasang, diautentikasi, disetujui, dan dijalankan di host yang benar-benar Anda gunakan. Selain itu, koneksi tersebut juga harus memiliki skenario kegagalan yang mudah dipahami. Server MCP yang berfungsi secara interaktif tetapi menunggu persetujuan dalam sesi tanpa pengawasan tetap berguna, tetapi tidak boleh digambarkan sebagai otomatisasi tanpa hambatan.

Petunjuk yang dapat digunakan kembali juga memiliki keterbatasan serupa. Berkas petunjuk yang panjang tidak menjamin kepatuhan, dan seperangkat aturan yang terlalu rumit dapat mengaburkan konteks atau menimbulkan kontradiksi. Pastikan panduan di repositori tetap singkat, dapat diuji, dan relevan dengan kode. Cantumkan perintah verifikasi yang wajib, area yang dilindungi, aturan gaya, serta kapan agen harus berhenti untuk meminta konfirmasi.

• Petunjuk proyek: aturan khusus repositori dan perintah verifikasi.
• Keterampilan: prosedur yang dapat digunakan kembali atau paket keahlian.
• MCP: koneksi ke alat dan data eksternal.
• Hook dan perintah: otomatisasi seputar peristiwa alur kerja yang telah ditentukan.

Perbandingan Codex dan Claude: Harga dan Batasan Penggunaan

Perbandingan paket langganan dasar dimulai dari $20 per bulan. Akses ke Codex sudah termasuk dalam paket $20 ChatGPT yang relevan, sedangkan paket Claude Pro seharga $20 per bulan di Amerika Serikat dan sudah mencakup Claude Code. Keduanya menawarkan tingkatan langganan konsumen dengan penggunaan lebih tinggi, yaitu $100 dan $200. Harga nominal yang serupa tidak berarti kapasitas yang sama.

Paket Claude Max 5x dikenakan biaya $100 per bulan, sedangkan paket Max 20x dikenakan biaya $200 per bulan. Istilah “5x” dan “20x” menggambarkan penggunaan per sesi relatif terhadap paket Pro, bukan jumlah tugas pemrograman yang dijamin. Paket Claude dan Claude Code berbagi batas sesi dan mingguan. Panjang konteks, file terlampir, pilihan model, dan penggunaan fitur dapat memengaruhi seberapa cepat kuota habis.

Kredit penggunaan opsional Claude dapat digunakan untuk melanjutkan pekerjaan yang memenuhi syarat setelah kuota penggunaan yang disertakan habis, jika fitur ini diaktifkan, dan kredit tersebut ditagih secara terpisah dengan tarif API standar. Otentikasi melalui kunci API merupakan jalur penagihan terpisah lainnya. Menyebut salah satu jalur tersebut sebagai “tak terbatas” akan menyembunyikan biaya marjinal yang sebenarnya.

Codex juga membedakan antara penggunaan dalam paket konsumen yang disertakan, kredit yang dibeli dan memenuhi syarat, serta penagihan API. Pesan lokal dan obrolan cloud memiliki jendela waktu lima jam yang sama, dan batasan mingguan mungkin juga berlaku. Kolom token dalam log CLI tidak dapat dikonversi secara langsung menjadi persentase lima jam, jumlah kredit langganan, atau tagihan API.

Untuk kegiatan pemrograman solo sesekali, tingkatan $20 di kedua sisi merupakan titik awal yang masuk akal. Pekerjaan harian di repositori dengan konteks yang panjang mungkin memerlukan tingkatan penggunaan yang lebih tinggi, tetapi hal ini hanya dapat dipertimbangkan setelah mengamati reset yang sebenarnya dan konsumsi tugas. Pekerjaan paralel yang intensif memerlukan perhatian ekstra: membayar untuk tingkatan yang lebih besar tidak menghilangkan kebutuhan untuk mengontrol konteks, membagi tugas, dan mengalokasikan pemrosesan yang mahal untuk pekerjaan yang memerlukan penilaian tinggi.

Hasil yang kami temukan dari uji perbandingan Codex vs Claude yang kami lakukan secara terkontrol

Kami membekukan empat petunjuk dalam bahasa Inggris, sebuah fixture Python yang terbuka untuk umum, soal-soal objektif, pedoman penilaian, dan aturan “hasil valid pertama” sebelum kedua agen dijalankan. Tugas-tugas yang diuji mencakup pemahaman terhadap repositori yang tidak dikenal, fitur multi-file, perbaikan bug DST, serta tinjauan kode beserta perbaikannya. Hasil yang valid tidak memerlukan intervensi manusia, dan keluaran yang lemah namun valid tidak dapat dijalankan ulang untuk mendapatkan skor yang lebih baik.

Codex dijalankan melalui proses CLI yang terisolasi dengan JSONL mentah, dan bidang token yang dihasilkan oleh CLI tetap dipertahankan. Sesi OAuth CLI Claude milik rekan kerja tersebut telah kedaluwarsa, sehingga Claude Code menggunakan koordinator dengan konteks subagen yang baru. Kami merekonstruksi tambalan Claude dalam salinan audit yang bersih dan menjalankan kembali pemeriksaan publik dan tersembunyi. Hal ini menghasilkan bukti praktis yang kredibel, namun tidak menghasilkan isolasi atau permukaan kontrol model yang identik.

Uji coba ini terlalu kecil untuk menilai kinerja pada repositori besar, semua bahasa pemrograman, semua tingkatan model, atau sesi otonom yang panjang. Selisih total satu poin sebaiknya diartikan sebagai “keduanya berhasil, dengan perbedaan cakupan tinjauan,” bukan sebagai peringkat universal.

Apa yang dilaporkan oleh pengguna sungguhan—dan seberapa jauh kita bisa mempercayainya

Umpan balik dari komunitas sangat berharga jika mencakup proyek, tugas, model, pengaturan upaya, dan rentang waktu. Umpan balik tersebut kurang bermakna jika sebuah postingan hanya melaporkan bahwa suatu produk “terasa lebih cerdas” atau “jauh lebih cepat.” Pengguna yang berbeda membandingkan repositori, tingkatan langganan, prompt, ekstensi, dan tingkat pengawasan yang berbeda-beda.

Contoh Reddit kontekstual di atas menunjukkan adanya trade-off dalam interaksi: pendekatan yang cepat dan bersifat percakapan mungkin membutuhkan lebih banyak perhatian, sementara pelaksanaan yang cermat mungkin terasa lebih lambat namun memerlukan lebih sedikit koreksi. Uji terkontrol kami hanya sebagian tumpang tindih dengan akun tersebut. Uji tersebut menemukan kecepatan yang bervariasi dan tidak adanya intervensi manusia dalam eksekusi yang valid, sehingga tidak dapat memvalidasi klaim "pengawasan". Inilah tepatnya mengapa bukti dari komunitas dan bukti terkontrol harus ditampilkan bersama tanpa menggabungkannya.

Komentar mengenai X harness mengemukakan poin penting kedua: hasil pemrograman merupakan bagian dari keseluruhan sistem, bukan sekadar label model. Kedua postingan tersebut tidak boleh diperlakukan sebagai data survei. Gunakanlah keduanya untuk mengidentifikasi pertanyaan-pertanyaan bagi percobaan Anda sendiri—jumlah intervensi, besarnya perbedaan, kualitas pengujian, dan pemulihan dari asumsi yang keliru.

Memperluas Codex dan Kode Claude dengan GlobalGPT

GlobalGPT adalah sebuah ruang kerja multi-model dan multimodal, bukan sebagai pengganti agen repositori bawaan. Peran praktisnya adalah untuk melengkapi host yang sudah ada: menggunakan model agen lain yang tersedia untuk mendapatkan pendapat kedua, tinjauan rencana, verifikasi dokumentasi, atau hasil khusus, sementara Codex atau Claude Code tetap bertanggung jawab atas akses repositori, perintah shell, pengujian, dan persetujuan.

GlobalGPT menerbitkan panduan CLI resmi untuk Kodeks dan Kode Claude, serta Cursor. Dalam uji integrasi T5 yang aman, antarmuka baris perintah (CLI) berhasil menyelesaikan tugas yang sama yang terhenti di kedua lingkungan yang dibandingkan. Di Codex, kami juga memverifikasi panggilan daftar model MCP yang hanya baca, serta menginstal, memuat, dan menggunakan Skill GlobalGPT.

Ringkasan Uji Integrasi # GlobalGPT

Ruang Lingkup ##

T5 mengukur integrasi GlobalGPT dan tidak termasuk dalam skor pengkodean Codex asli. Yukie tidak digunakan.

## Penguncian dan Kesiapan Model

- Model A: `gpt-5.6-sol`
- Model B: `gpt-5.6-luna`
- Kedua model tersebut muncul dalam daftar model aktif.
- Kedua probe kesiapan ringan menghasilkan teks yang valid dan dapat diparsing.
- Model dikunci sebelum panggilan keluaran T5A dan T5B formal.

## Hasil CLI formal

| Tugas | Model | Status | Durasi | Token prompt | Token hasil | Judul yang diperlukan |
|---|---|---|---:|---:|---:|---:|
| T5A | gpt-5.6-sol | Valid | 27 detik | 2.116 | 1.207 | 6/6 |
| T5B | gpt-5.6-luna | Valid | 14 detik | 2.116 | 1.441 | 6/6 |

Kedua panggilan formal tersebut menggunakan tugas perencanaan produk bahasa Inggris yang dibekukan yang sama melalui `glbgpt exec`, mengembalikan keluaran yang hanya terlihat dalam bahasa Inggris, dan tidak memaparkan kredensial apa pun. Tidak terjadi pengulangan kualitas.

## Hasil MCP

- `codex mcp list` menunjukkan bahwa `globalgpt` diaktifkan.
- Sesi Codex non-interaktif menemukan dan mencoba `mcp__globalgpt__glbgpt_list_models`, tetapi panggilan tersebut dibatalkan karena persetujuan MCP tanpa pengawasan tidak tersedia. Tidak ada pengaturan keamanan yang dilonggarkan.
- Sesi Codex interaktif yang aktif berhasil memanggil alat MCP GlobalGPT yang hanya dapat dibaca dan menerima sembilan model obrolan.
- Hasil: akses MCP interaktif terverifikasi; eksekusi MCP non-interaktif tanpa pengawasan tetap memiliki batasan persetujuan.

Hasil Keterampilan ##

- Keterampilan GlobalGPT dan GlobalGPT Coding telah diinstal di direktori keterampilan Codex melalui tautan ke paket keterampilan CLI yang disertakan.
- Keterampilan GlobalGPT dimuat dan dipantau untuk pemeriksaan sesi yang dikonfigurasi, pemilihan model langsung, kesiapan, opsi yang aman bagi kredit, dan penanganan kegagalan.
- Hasil: terpasang dan diuji dalam alur kerja Codex yang aktif.

## Kesimpulan Terbatas

Pelaksanaan ini memverifikasi panggilan CLI GlobalGPT yang berfungsi, panggilan MCP GlobalGPT interaktif read-only dari Codex, serta jalur keterampilan GlobalGPT yang telah diinstal dan digunakan. Hal ini tidak membuktikan bahwa setiap model, alat media, host, akun, atau konfigurasi MCP tanpa pengawasan berfungsi. Hal ini juga tidak menguji Yukie atau mendukung klaim bahwa GlobalGPT menggantikan Codex atau Claude Code.

Batasan ini penting. Pengujian Claude yang dilakukan rekan kerja tersebut memverifikasi jalur CLI, bukan MCP di sisi Claude. Skill tersebut memang terpasang di sana, tetapi tidak digunakan untuk panggilan yang macet. Upaya Codex MCP tanpa pengawasan tetap memerlukan persetujuan manual. Ketersediaan model dan kredit juga bergantung pada paket GlobalGPT saat ini, sehingga pengembang sebaiknya memeriksa daftar yang berlaku daripada mengasumsikan bahwa setiap model sudah termasuk.

GlobalGPT juga mencakup alur kerja berbasis gambar, video, audio, dan panduan Agen. Entri Slides, Document, dan Image di Yukie termasuk dalam kategori yang berbeda: entri-entri ini menawarkan templat yang jelas dan panduan langkah demi langkah melalui browser untuk tugas-tugas non-kode. Hal ini mungkin lebih mudah daripada membuka CLI pemrograman untuk membuat presentasi atau dokumen terstruktur, tetapi tidak menggantikan kegiatan membaca repositori, menjalankan pengujian, atau meninjau kode.

Agen pengkodean mana yang sebaiknya dipilih oleh seorang pengembang independen?

• Pilih Codex ketika eksekusi yang ringkas dan terbatasi, kombinasi permukaan yang tersedia, atau bukti eksekusi yang tersedia dalam konfigurasi Anda sesuai dengan cara Anda bekerja.
• Pilih Kode Claude ketika loop terminal percakapan, fitur penyesuaian yang telah Anda verifikasi, atau perilaku peninjauan yang lebih luas seperti yang diamati pada fixture kami menjadi lebih penting.
• Gunakan salah satu dari keduanya untuk repositori yang belum dikenal hanya setelah melalui tahap verifikasi arsitektur dan risiko dalam mode baca saja. Kedua alat tersebut berhasil menangani tugas tersebut dengan baik.
• Gunakan keduanya secara selektif ketika tinjauan oleh agen kedua sebanding dengan biaya langganan dan koordinasi tambahan. Minta alat kedua untuk meninjau ulang perbedaan atau rencana, alih-alih sekadar mengulangi tugas tersebut tanpa pertimbangan.
• Tambahkan GlobalGPT ketika perutean multi-model atau pekerjaan multimodal merupakan lapisan yang belum ada. Pertahankan operasi repositori asli di host pengkodean.

Uji coba selama tujuh hari lebih informatif daripada papan peringkat. Pilih satu fitur nyata namun bukan fitur produksi, bug, dan tinjauan. Bekukan prompt dan perintah keberhasilan. Catat perbedaan (diff) valid pertama, tes yang lulus, waktu yang dihabiskan, intervensi manusia, cakupan yang tidak terduga, dan bagaimana pekerjaan tersebut memengaruhi kuota penggunaan Anda. Produk yang lebih baik adalah produk yang kesalahannya dapat Anda deteksi dan alur kerjanya dapat Anda pertahankan.

Pertanyaan Umum (FAQ) tentang Codex vs Kode Claude

Apakah Codex lebih baik daripada Kode Claude?

Tidak secara umum. Keduanya berhasil menyelesaikan keempat tugas dalam rangkaian uji coba kami. Claude Code unggul dalam cakupan tinjauan, sementara Codex lebih ringkas dalam beberapa aspek implementasi dan perbaikan bug.

Manakah yang lebih baik untuk repositori berukuran besar?

Alat kecil kami tidak bisa menjawab pertanyaan itu. Silakan uji keduanya pada tugas arsitektur read-only dari repositori Anda sendiri sebelum mengizinkan perubahan.

Agen pengkodean mana yang membutuhkan pengawasan lebih sedikit?

Hal itu bergantung pada kejelasan tugas, pengaturan model, petunjuk di repositori, dan gaya interaksi yang diinginkan. Seorang pengguna Reddit melaporkan pola pengawasan yang berbeda-beda, namun pengalaman pribadi tersebut bukanlah aturan yang berlaku secara umum untuk seluruh produk.

Mana yang lebih murah?

Tingkat langganan utama ditetapkan pada $20, $100, dan $200 per bulan, namun kapasitas yang disertakan dan mekanisme batasnya berbeda-beda. Kredit opsional dan penagihan API diatur secara terpisah.

Apakah Claude dan Claude Code Share memiliki batasan penggunaan?

Ya. Claude dan Claude Code menggunakan batas sesi bersama dan batas mingguan pada paket Pro atau Max yang terhubung.

Apakah tugas lokal dan tugas cloud di Codex memiliki batas yang sama?

Pesan lokal dan obrolan berbasis cloud memiliki batas waktu lima jam, dan batasan mingguan mungkin juga berlaku.

Apakah GlobalGPT dapat menggantikan Codex atau Claude Code?

Tidak. Sistem ini dapat memperluas kedua alur kerja tersebut dengan model tambahan, CLI, MCP, Skills, dan alat multimodal, namun akses ke repositori serta perilaku agen pemrograman tetap berada di sistem tuan rumah.

Apakah saya bisa menggunakan GlobalGPT dari kedua produk tersebut?

GlobalGPT menyediakan panduan resmi CLI untuk keduanya. Kami telah memverifikasi penggunaan CLI di kedua lingkungan tersebut serta penggunaan MCP dan Skill di Codex, dengan batasan persetujuan untuk MCP tanpa pengawasan.

Harga, ketentuan paket, integrasi, dan sumber referensi telah diverifikasi pada bulan Juli 2026. Rincian produk dapat berubah.

Buka GlobalGPT jika Anda ingin menambahkan lapisan multi-model dan multimodal ke alur kerja pemrograman yang sudah ada.