Engineering Process

Developer workflow

Pilih ticket dengan acceptance criteria jelas.
Branch dari dev. dev = integrasi, main = release. Pastikan dev up-to-date dulu.
Baca AGENTS.md repo + .ai/instructions/* yang relevan.
Implement slice terkecil yang jalan, ikuti konvensi lokal.
Test di level yang tepat (unit / integration / E2E).
Jalanin required commands lokal (beda per repo — lihat bawah).
Buka PR ke dev, isi semua section template.
Address review sampai approval + checks hijau.
Merge sesuai norma repo (squash/rebase). Jangan force-push branch yang di-protect.

Git workflow (all repos)

Base branch = dev. PR target dev, bukan main (kecuali release yang di-approve).
Satu fitur → satu branch dari dev: <type>/<short-description>.
Banyak fitur paralel → worktree, tiap worktree tetap branch dari dev.
Commit atomik — satu perubahan logis per commit. Pesan commit jelasin kenapa.
Conventional Commits (di-enforce Commitlint di repo yang punya): feat, fix, perf, refactor, deps, docs, test, build, ci, chore.

Cross-repo merge order

Untuk perubahan yang nyentuh banyak repo, urutannya:

backend / API dulu → web / mobile → deploy / auth.

Kalau kontrak request/response berubah, notify konsumer (web & mobile) di PR/ticket yang sama.

Spec-driven pipeline

Fitur non-trivial jalan lewat pipeline: clarify → specify → plan → AI-council review → apply fixes → tasks → implement → verify → commit. Entry point (workspace): /feature (lintas-repo), /entity (HR entity/migration), /api-change (kontrak API), /fix (bug single-repo), /review-loop (verifikasi implementasi vs spec). Detail: workspace CLAUDE.md → “Orchestration Workflows”.

Required commands before PR

Beda per repo — jalanin yang ada di package.json / Makefile branch itu. Contoh:

haer-platform-web: pnpm install --frozen-lockfile, pnpm lint, pnpm format:check, pnpm build (+ pnpm typecheck / test:* kalau ada).
haer-platform-api: lint + test + build; migration checks (lihat Data & Migrations).
haer-platform-bgjobs (Go): go build ./..., go test ./....
haer-connector (Python): uv run ruff check ., test suite.

Kalau script-nya belum ada, jangan diarang-arang — catat gap di PR, buka follow-up.

PR contents (required)

Pakai template .github/pull_request_template.md. Minimal: ## Summary, konfirmasi patuh AGENTS.md, compliance checklist (RBAC, audit, secrets, nullable, migration, API contract, tests, build), dan ## Test Evidence (bukti konkret). Setiap PR wajib punya rollback steps.

Risk classification

Tulis di PR: Low (UI polish, refactor internal ber-test), Medium (fitur baru, konsumer API baru), High (auth/rbac/permission/security, file migration, governance), Critical (access-context, sidebar policy, proxy, jalur data lintas-tenant). Makin tinggi → makin butuh Tech Lead + reviewer terkait.

Code review

Cara review lengkap — tanggung jawab author & reviewer, checklist, etika, approval bar — ada di How We Review PRs. Ringkasnya: review di action bukan cuma route, cek kontrak API + tenant scoping + RBAC + state + test yang nguji intent, dan jangan approve kalau ada test di-skip biar hijau.

Decisions (ADR / spec)

Keputusan arsitektur/desain direkam sebagai ADR atau spec doc (Spec Kit, di specs/), bukan cuma di kepala. Ini yang bikin kenapa sebuah keputusan diambil tetap kebaca berbulan-bulan kemudian.