Skip to content

Instantly share code, notes, and snippets.

@rickicode
Created May 31, 2026 18:44
Show Gist options
  • Select an option

  • Save rickicode/ba944b90142a3584b5fa8ac4e5220872 to your computer and use it in GitHub Desktop.

Select an option

Save rickicode/ba944b90142a3584b5fa8ac4e5220872 to your computer and use it in GitHub Desktop.
Hermes Agent code-audit skill

Referensi: Kriteria Audit per Dimensi (D1–D9)


D1 — Kelengkapan Implementasi

Tujuan: Tidak ada kode yang hanya berpura-pura bekerja.

Red Flags — Tandai FAIL jika ditemukan:

// Stub / fungsi kosong
function calculateDiscount() { return 0; }
function sendEmail() { return true; }
async function syncInventory() {}

// TODO / placeholder yang belum diselesaikan
// TODO: implement this later
// FIXME: this is a hack

// Data hardcoded yang harusnya dinamis
const TAX_RATE = 0.11;                      // ok jika konstanta resmi
const users = [{ id: 1, name: "Admin" }];   // RED FLAG jika ini "data produksi"
const STORE_ID = "store_001";               // RED FLAG jika multi-store

// Mock yang tertinggal di production path
if (process.env.NODE_ENV !== "test") {
  // logic asli tidak pernah jalan saat test
}
Math.random() > 0.5 ? successFlow() : failFlow();  // logika random = mock

// Import yang tidak dipakai (indikasi fitur tidak jadi diimplementasi)
import { PaymentGateway } from './payment'; // tapi tidak pernah dipanggil

Untuk MODE A — Cek per fitur di PRD:

Setiap fitur di PRD harus bisa di-trace ke fungsi/komponen nyata di kode. "Ada di kode" artinya: ada fungsi, dipanggil, return nilai nyata, dan terhubung ke UI/API.

Untuk MODE C — Pattern yang dicurigai "belum selesai":

  • Fungsi yang hanya ada definisi tapi tidak pernah dipanggil dari manapun
  • Komponen UI yang dirender tapi tidak ada event handler-nya
  • Database schema yang punya kolom tapi tidak ada kode yang mengisinya
  • Route/endpoint yang ada tapi controller-nya hanya res.json({ status: 'ok' })

D2 — Ketepatan Algoritma & Logika Bisnis

Tujuan: Kode menghasilkan output yang benar secara matematis dan logis.

Checklist:

  • Kalkulasi finansial benar (urutan operasi: diskon → pajak, bukan terbalik)
  • Kondisi boolean tidak terbalik (> vs >=, && vs ||, negasi ganda)
  • Loop tidak off-by-one (< vs <=, index mulai dari 0 atau 1)
  • Floating point: apakah aman? (gunakan integer sen/rupiah untuk uang)
  • Pembulatan: Math.floor, Math.ceil, atau Math.round? Mana yang tepat?
  • Date/time: timezone dihandle? Format konsisten?
  • Sorting: ascending/descending sesuai kebutuhan?
  • Pagination: offset/limit dihitung dengan benar?

Contoh Bug Umum:

// SALAH — urutan operasi: diskon harusnya dari harga asli
const total = (price * 1.11) * (1 - discount);  // diskon dari harga+pajak
// BENAR
const total = price * (1 - discount) * 1.11;    // diskon dulu, pajak kemudian

// SALAH — off-by-one
for (let i = 0; i <= arr.length; i++) { arr[i].name }  // crash di i === length
// BENAR
for (let i = 0; i < arr.length; i++) { ... }

// SALAH — float precision
0.1 + 0.2 === 0.3  // false di JavaScript!
// BENAR — untuk uang, gunakan integer (dalam sen/rupiah terkecil)
const totalCents = Math.round(price * 100) + Math.round(tax * 100);

// SALAH — logika terbalik
if (!isLoggedIn && hasPermission) { grantAccess(); }
// harusnya: if (isLoggedIn && hasPermission)

// SALAH — tanggal tanpa timezone
new Date("2024-01-15")  // bisa jadi hari sebelumnya di timezone tertentu
// BENAR
new Date("2024-01-15T00:00:00+07:00")  // eksplisit timezone

Verifikasi Manual untuk Logika Kritis:

Untuk kalkulasi finansial, tulis contoh hitungan eksplisit dan verifikasi:

Contoh: Harga Rp100.000, diskon 10%, PPN 11%
Expected: 100.000 × (1 - 0.1) = 90.000 → × 1.11 = 99.900
Kode menghasilkan: [trace nilai di kode]
Match? [Ya / Tidak]

D3 — Penanganan Edge Case

Tujuan: Tidak crash atau hasil salah pada input di luar kondisi normal.

Edge Case Universal:

// NULL / UNDEFINED
const name = user.profile.name;           // crash jika profile null
const name = user?.profile?.name ?? '-';  // aman

// ARRAY KOSONG
const first = items[0].price;             // crash jika items = []
const first = items[0]?.price ?? 0;       // aman

// DIVIDE BY ZERO
const avg = total / count;                // NaN / Infinity jika count = 0
const avg = count > 0 ? total / count : 0;

// STRING KOSONG / WHITESPACE ONLY
if (input) { process(input); }            // lolos jika input = "   "
if (input?.trim()) { process(input); }    // benar

Edge Case Spesifik Domain POS / Keuangan:

- Harga = 0 (item gratis)
- Diskon = 0% dan 100%
- Quantity = 0 (hapus item?) dan negatif (return?)
- Total transaksi = 0
- Refund > nilai transaksi asli
- Stok = 0 saat checkout
- Dua user checkout item terakhir bersamaan (race condition stok)
- Payment gagal setelah order dibuat
- Printer struk tidak terhubung
- Barcode tidak ditemukan di database

Edge Case Form / Input:

- Submit dua kali cepat (double-click, double-submit)
- Paste 10.000 karakter ke input text
- Karakter spesial: <script>, ', ", \n, emoji
- Input yang hanya spasi
- Angka negatif di field quantity/harga
- Tanggal tidak valid (31 Februari)

D4 — Error Handling & Resiliensi

Tujuan: Error tidak menyebabkan crash atau data korup — dan bisa di-debug.

Pola yang Harus Ditandai FAIL:

// Error ditelan — BERBAHAYA
try { await saveOrder(); } catch (e) {}
try { await saveOrder(); } catch (e) { console.log(e); }  // log tapi tidak handle

// Unhandled promise — BERBAHAYA
fetchProducts().then(setProducts);  // tanpa .catch()
// atau di async function tanpa try/catch:
async function loadData() {
  const data = await api.get('/products');  // tidak ada try/catch
  setData(data);
}

// Error message tidak berguna
catch (e) { throw new Error("Terjadi kesalahan"); }
catch (e) { res.json({ error: "Error" }); }

// Async tanpa await — data tidak tersimpan tapi dianggap sukses
function createOrder(data) {
  db.save(data);           // tidak di-await!
  return { success: true }; // selalu sukses padahal save belum selesai
}

Yang Harus Ada:

// BENAR — error handling lengkap
async function processPayment(orderId, amount) {
  try {
    const result = await paymentGateway.charge(amount);
    await db.updateOrderStatus(orderId, 'paid');
    return { success: true, transactionId: result.id };
  } catch (error) {
    logger.error('Payment failed', { orderId, amount, error: error.message });
    await db.updateOrderStatus(orderId, 'payment_failed');
    throw new PaymentError(`Pembayaran gagal: ${error.message}`, { orderId });
  }
}

Checklist:

  • Semua async/await punya try/catch
  • Error message menyebut konteks (fungsi apa, data apa, kenapa)
  • Error di-log dengan level yang tepat (error untuk bug, warn untuk expected failure)
  • UI menampilkan pesan yang layak — bukan blank screen / spinner selamanya
  • Sensitive data tidak masuk ke log (password, nomor kartu, token)
  • Timeout diset untuk operasi jaringan yang bisa hang

D5 — Integritas Data & Atomisitas

Tujuan: Data tidak pernah dalam keadaan setengah-tersimpan.

Red Flag — Operasi Non-Atomik:

// BERBAHAYA — jika langkah 2 gagal, stok sudah berkurang tapi order tidak dibuat
async function checkout(cartItems, userId) {
  for (const item of cartItems) {
    await db.decrementStock(item.productId, item.qty);  // langkah 1
  }
  const order = await db.createOrder(userId, cartItems); // langkah 2 — bisa gagal!
  await db.createOrderItems(order.id, cartItems);        // langkah 3 — bisa gagal!
}

// BENAR — atomic dengan transaksi
async function checkout(cartItems, userId) {
  return await db.transaction(async (trx) => {
    for (const item of cartItems) {
      await trx.decrementStock(item.productId, item.qty);
    }
    const order = await trx.createOrder(userId, cartItems);
    await trx.createOrderItems(order.id, cartItems);
    return order;
  });
}

Checklist:

  • Create + update yang saling tergantung dibungkus transaksi
  • Delete tidak meninggalkan orphan record (foreign key constraint atau cascade)
  • Stok/inventory diupdate atomik dengan pembuatan order
  • Tidak ada operasi baca-ubah-tulis tanpa locking (race condition)
  • Soft delete diimplementasi konsisten (tidak ada yang hard delete kecuali disengaja)

D6 — Keamanan

Tujuan: Tidak ada celah yang bisa dieksploitasi.

Critical Red Flags:

// HARDCODED SECRET — CRITICAL
const JWT_SECRET = "mysecretkey123";
const DB_PASSWORD = "admin123";
const API_KEY = "sk-prod-abc...";

// SQL INJECTION — CRITICAL
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`;
// BENAR: gunakan parameterized query
const query = db.raw('SELECT * FROM users WHERE email = ?', [req.body.email]);

// XSS — CRITICAL
element.innerHTML = userInput;
res.send(`<h1>Hello ${req.query.name}</h1>`);
// BENAR: sanitize atau gunakan text content
element.textContent = userInput;

// IDOR — akses tanpa cek kepemilikan — CRITICAL
app.get('/api/orders/:id', async (req, res) => {
  const order = await Order.findById(req.params.id);
  // tidak cek apakah order.userId === req.user.id !
  res.json(order);
});

// AUTH TIDAK DICEK — CRITICAL
app.delete('/api/products/:id', async (req, res) => {
  // tidak ada middleware auth!
  await Product.delete(req.params.id);
  res.json({ success: true });
});

Checklist:

  • Semua secret dari environment variable, bukan hardcoded
  • Semua input user di-sanitize/validate sebelum diproses
  • Parameterized query dipakai — tidak ada string interpolation ke SQL
  • Setiap endpoint sensitif punya middleware auth
  • Setiap endpoint data user punya cek kepemilikan (userId match)
  • CORS tidak * untuk production (kecuali public API)
  • Password di-hash (bcrypt/argon2) — tidak disimpan plain text
  • Sensitive data tidak masuk response yang tidak perlu (password hash, token)

D7 — Performa & Efisiensi

Tujuan: Tidak ada bottleneck yang meledak saat production load.

N+1 Query — Paling Sering Terjadi:

// RED FLAG — N+1: 1 query untuk orders + N query untuk tiap order
const orders = await Order.findAll();
for (const order of orders) {
  order.items = await OrderItem.findAll({ where: { orderId: order.id } });
}

// BENAR — eager loading atau join
const orders = await Order.findAll({
  include: [{ model: OrderItem }]
});

Checklist:

  • Loop yang melakukan query database di dalamnya = N+1, harus diperbaiki
  • Endpoint list punya pagination (limit/offset atau cursor)
  • Query yang filter/sort punya index di kolom yang dipakai
  • Tidak ada SELECT * untuk tabel dengan banyak kolom
  • Tidak ada console.log berlebihan di production path
  • Tidak ada blocking sync call di dalam async handler

D8 — Keterbacaan & Maintainability

(Advisory — tidak memblokir deploy)

Yang Dinilai:

  • Nama variabel/fungsi deskriptif (getActiveOrders bukan getData)
  • Fungsi tidak > 50 baris tanpa alasan kuat
  • Magic number diganti konstanta (TAX_RATE = 0.11 bukan * 0.11 langsung)
  • Kode yang di-comment-out tanpa penjelasan dihapus
  • Komentar ada untuk logika non-obvious

D9 — Kesesuaian PRD / Referensi

(Hanya Mode A dan Mode B)

Mode A — Output Wajib:

KESESUAIAN PRD
Fitur di PRD                    | Status          | Lokasi di Kode / Catatan
--------------------------------|-----------------|-------------------------
[nama fitur dari PRD]           | ✅ Implemented  | [file › fungsi]
[nama fitur dari PRD]           | ❌ Missing      | Tidak ditemukan
[nama fitur dari PRD]           | ⚠️ Partial      | Ada tapi [apa yang kurang]
[nama fitur dari PRD]           | 🔄 Modified     | Berbeda dari spec, konfirmasi?

Mode B — Output Wajib:

KESESUAIAN REFERENSI
Fungsi/Behavior di Referensi    | Status             | Catatan
--------------------------------|--------------------|--------
[nama fungsi/behavior]          | ✅ Equivalent      | -
[nama fungsi/behavior]          | ❌ Missing         | [dampak]
[nama fungsi/behavior]          | 🔄 Changed         | [apakah disengaja?]
[nama fungsi/behavior]          | ✨ Added (baru)    | [tidak ada di referensi]

Referensi: Fix Patterns

Pattern fix siap pakai yang digunakan AI saat Fase 4 (Autofix). Dibaca sebelum memulai autofix untuk memastikan fix yang dihasilkan konsisten dan benar.


FP-01 — Stub / Fungsi Tidak Terimplementasi

Deteksi: Fungsi hanya return default, throw "not implemented", atau body kosong.

Prinsip fix:

  • Implementasi nyata harus sesuai dengan nama fungsi dan context penggunaannya
  • Trace semua pemanggil fungsi ini untuk memahami expected input/output
  • Jika logika bisnis tidak bisa dipastikan dari kode → buat implementasi dengan // AUTOFIX: skeleton — perlu review logika bisnis dan isi dengan logika paling masuk akal
// SEBELUM — stub
async function calculateTotal(items) {
  return 0; // TODO: implement
}

// SESUDAH — implementasi nyata
async function calculateTotal(items) {
  // AUTOFIX: implementasi kalkulasi total dari stub
  if (!items || items.length === 0) return 0;
  return items.reduce((sum, item) => {
    const itemTotal = (item.price ?? 0) * (item.quantity ?? 1);
    return sum + itemTotal;
  }, 0);
}

FP-02 — Missing Try/Catch pada Async

Deteksi: async function atau .then() tanpa error handling.

Prinsip fix:

  • Wrap seluruh async operation dalam try/catch
  • Error harus di-log dengan konteks (nama fungsi, parameter kritis)
  • Re-throw dengan error yang informatif, atau return error object yang konsisten
  • Jangan telan error diam-diam
// SEBELUM — tidak ada error handling
async function saveOrder(orderData) {
  const order = await db.orders.create(orderData);
  await updateStock(order.items);
  return order;
}

// SESUDAH — dengan error handling
async function saveOrder(orderData) {
  // AUTOFIX: tambah try/catch untuk async operation
  try {
    const order = await db.orders.create(orderData);
    await updateStock(order.items);
    return order;
  } catch (error) {
    console.error('[saveOrder] Gagal menyimpan order:', {
      error: error.message,
      orderData: { userId: orderData.userId, itemCount: orderData.items?.length }
    });
    throw new Error(`Gagal menyimpan order: ${error.message}`);
  }
}

FP-03 — Operasi Non-Atomik (Missing Transaction)

Deteksi: Beberapa operasi DB berurutan tanpa transaksi, di mana gagalnya satu akan meninggalkan data inkonsisten.

Prinsip fix:

  • Identifikasi semua operasi yang harus berhasil atau gagal bersama
  • Bungkus dalam db.transaction() (atau equivalent ORM yang dipakai)
  • Pastikan semua operasi dalam transaksi menggunakan trx bukan db langsung
// SEBELUM — non-atomik
async function processCheckout(userId, cartItems) {
  for (const item of cartItems) {
    await db.inventory.decrement({ id: item.productId }, item.qty);
  }
  const order = await db.orders.create({ userId, status: 'pending' });
  const orderItems = await db.orderItems.bulkCreate(
    cartItems.map(i => ({ orderId: order.id, ...i }))
  );
  return order;
}

// SESUDAH — atomik dengan transaksi
async function processCheckout(userId, cartItems) {
  // AUTOFIX: bungkus dalam transaksi agar atomik
  return await db.transaction(async (trx) => {
    for (const item of cartItems) {
      await db.inventory.decrement(
        { id: item.productId },
        item.qty,
        { transaction: trx }
      );
    }
    const order = await db.orders.create(
      { userId, status: 'pending' },
      { transaction: trx }
    );
    await db.orderItems.bulkCreate(
      cartItems.map(i => ({ orderId: order.id, ...i })),
      { transaction: trx }
    );
    return order;
  });
}

FP-04 — Missing Edge Case Guard

Deteksi: Operasi pada nilai yang bisa null/undefined/empty tanpa guard.

Prinsip fix:

  • Tambahkan guard clause di awal fungsi (early return pattern)
  • Gunakan optional chaining ?. dan nullish coalescing ??
  • Untuk array: cek .length sebelum akses index atau .reduce()
// SEBELUM — tidak ada guard
function getOrderSummary(order) {
  const itemCount = order.items.length;
  const total = order.items.reduce((sum, i) => sum + i.price, 0);
  const firstItem = order.items[0].name;
  return { itemCount, total, firstItem };
}

// SESUDAH — dengan guard
function getOrderSummary(order) {
  // AUTOFIX: tambah guard untuk null/empty
  if (!order) return null;
  const items = order.items ?? [];
  const itemCount = items.length;
  const total = items.reduce((sum, i) => sum + (i.price ?? 0), 0);
  const firstItem = items[0]?.name ?? '-';
  return { itemCount, total, firstItem };
}

FP-05 — SQL Injection / Parameterized Query

Deteksi: String interpolasi langsung ke query SQL.

Prinsip fix:

  • Ganti interpolasi dengan parameterized query sesuai library yang dipakai
  • Jangan ubah logika query, hanya cara passing parameter
// SEBELUM — vulnerable
const user = await db.raw(`SELECT * FROM users WHERE email = '${email}'`);
const product = await db.raw(
  `SELECT * FROM products WHERE name LIKE '%${search}%'`
);

// SESUDAH — parameterized
// AUTOFIX: ganti string interpolation ke parameterized query
const user = await db.raw('SELECT * FROM users WHERE email = ?', [email]);
const product = await db.raw(
  'SELECT * FROM products WHERE name LIKE ?',
  [`%${search}%`]
);

// Atau jika pakai Sequelize/Prisma ORM:
const user = await User.findOne({ where: { email } });
const products = await Product.findAll({
  where: { name: { [Op.like]: `%${search}%` } }
});

FP-06 — XSS via innerHTML

Deteksi: element.innerHTML = userInput atau template literal ke innerHTML.

Prinsip fix:

  • Ganti innerHTML dengan textContent untuk teks biasa
  • Jika butuh render HTML: gunakan library sanitizer (DOMPurify)
  • Di React: hindari dangerouslySetInnerHTML, jika terpaksa pakai sanitize dulu
// SEBELUM — XSS vulnerable
element.innerHTML = userInput;
div.innerHTML = `<span>${user.comment}</span>`;

// SESUDAH — safe
// AUTOFIX: ganti innerHTML ke textContent untuk mencegah XSS
element.textContent = userInput;

// Jika memang perlu render HTML (misal: rich text dari CMS):
import DOMPurify from 'dompurify';
element.innerHTML = DOMPurify.sanitize(userInput);

FP-07 — Hardcoded Secret / Credential

Deteksi: API key, password, secret, token langsung di kode.

Prinsip fix:

  • Pindah ke environment variable
  • Tulis placeholder yang jelas
  • Tambahkan validasi bahwa env var ada saat startup
// SEBELUM — hardcoded
const JWT_SECRET = "supersecretkey123";
const DB_URL = "postgresql://admin:password@localhost:5432/mydb";
const MIDTRANS_KEY = "SB-Mid-server-xxx";

// SESUDAH — env variable
// AUTOFIX: pindah secret ke environment variable
const JWT_SECRET = process.env.JWT_SECRET;
const DB_URL = process.env.DATABASE_URL;
const MIDTRANS_KEY = process.env.MIDTRANS_SERVER_KEY;

// Tambahkan validasi startup (letakkan di file config/env.js atau app entry):
const REQUIRED_ENV = ['JWT_SECRET', 'DATABASE_URL', 'MIDTRANS_SERVER_KEY'];
for (const key of REQUIRED_ENV) {
  if (!process.env[key]) {
    throw new Error(`Environment variable ${key} tidak ditemukan. Cek file .env`);
  }
}

FP-08 — Missing Auth / Ownership Check

Deteksi: Endpoint yang mengakses/modifikasi data tanpa cek autentikasi atau kepemilikan (IDOR — Insecure Direct Object Reference).

Prinsip fix:

  • Auth check: pastikan middleware auth dipasang sebelum handler
  • Ownership check: bandingkan resource.userId dengan req.user.id
  • Kembalikan 403 (bukan 404) jika ownership tidak cocok
// SEBELUM — tidak ada auth + tidak ada ownership check
app.get('/api/orders/:id', async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order);
});

app.delete('/api/orders/:id', async (req, res) => {
  await Order.delete(req.params.id);
  res.json({ success: true });
});

// SESUDAH — dengan auth middleware + ownership check
// AUTOFIX: tambah auth middleware dan ownership check
app.get('/api/orders/:id', requireAuth, async (req, res) => {
  try {
    const order = await Order.findById(req.params.id);
    if (!order) return res.status(404).json({ error: 'Order tidak ditemukan' });
    if (order.userId !== req.user.id) {
      return res.status(403).json({ error: 'Akses ditolak' });
    }
    res.json(order);
  } catch (error) {
    console.error('[GET /orders/:id]', error.message);
    res.status(500).json({ error: 'Terjadi kesalahan server' });
  }
});

app.delete('/api/orders/:id', requireAuth, async (req, res) => {
  try {
    const order = await Order.findById(req.params.id);
    if (!order) return res.status(404).json({ error: 'Order tidak ditemukan' });
    if (order.userId !== req.user.id) {
      return res.status(403).json({ error: 'Akses ditolak' });
    }
    await Order.delete(req.params.id);
    res.json({ success: true });
  } catch (error) {
    console.error('[DELETE /orders/:id]', error.message);
    res.status(500).json({ error: 'Terjadi kesalahan server' });
  }
});

FP-09 — N+1 Query

Deteksi: Loop yang melakukan query database di setiap iterasinya.

Prinsip fix:

  • Kumpulkan semua ID terlebih dahulu, lalu batch fetch dalam satu query
  • Atau gunakan eager loading / JOIN jika ORM mendukung
  • Map hasil batch ke dalam struktur yang dibutuhkan
// SEBELUM — N+1 query
async function getOrdersWithProducts(userId) {
  const orders = await Order.findAll({ where: { userId } });
  for (const order of orders) {
    order.items = await OrderItem.findAll({ where: { orderId: order.id } });
    for (const item of order.items) {
      item.product = await Product.findById(item.productId); // N+1 di sini!
    }
  }
  return orders;
}

// SESUDAH — batch / eager loading
// AUTOFIX: ganti N+1 dengan eager loading
async function getOrdersWithProducts(userId) {
  // Opsi 1: Eager loading (Sequelize)
  const orders = await Order.findAll({
    where: { userId },
    include: [{
      model: OrderItem,
      include: [{ model: Product }]
    }]
  });
  return orders;

  // Opsi 2: Manual batch jika ORM tidak support include bertingkat
  // const orders = await Order.findAll({ where: { userId } });
  // const orderIds = orders.map(o => o.id);
  // const items = await OrderItem.findAll({ where: { orderId: orderIds } });
  // const productIds = [...new Set(items.map(i => i.productId))];
  // const products = await Product.findAll({ where: { id: productIds } });
  // const productMap = Object.fromEntries(products.map(p => [p.id, p]));
  // const itemMap = items.reduce((acc, item) => {
  //   item.product = productMap[item.productId];
  //   (acc[item.orderId] ??= []).push(item);
  //   return acc;
  // }, {});
  // return orders.map(o => ({ ...o.toJSON(), items: itemMap[o.id] ?? [] }));
}

FP-10 — Missing Input Validation

Deteksi: Data dari user/request langsung dipakai tanpa validasi format/tipe/range.

Prinsip fix:

  • Validasi di layer paling atas (controller/handler), sebelum masuk ke service/DB
  • Cek: tipe data, required fields, range nilai, format (email, tanggal, dll.)
  • Return 400 dengan pesan yang jelas jika validasi gagal
// SEBELUM — tidak ada validasi
app.post('/api/products', async (req, res) => {
  const product = await Product.create(req.body);
  res.json(product);
});

// SESUDAH — dengan validasi
// AUTOFIX: tambah input validation sebelum proses
app.post('/api/products', requireAuth, async (req, res) => {
  const { name, price, stock, categoryId } = req.body;

  // Validasi required fields
  const missing = [];
  if (!name?.trim()) missing.push('name');
  if (price === undefined || price === null) missing.push('price');
  if (stock === undefined || stock === null) missing.push('stock');
  if (missing.length > 0) {
    return res.status(400).json({
      error: `Field wajib tidak ada: ${missing.join(', ')}`
    });
  }

  // Validasi tipe dan range
  if (typeof price !== 'number' || price < 0) {
    return res.status(400).json({ error: 'price harus berupa angka non-negatif' });
  }
  if (!Number.isInteger(stock) || stock < 0) {
    return res.status(400).json({ error: 'stock harus berupa integer non-negatif' });
  }

  try {
    const product = await Product.create({ name: name.trim(), price, stock, categoryId });
    res.status(201).json(product);
  } catch (error) {
    console.error('[POST /products]', error.message);
    res.status(500).json({ error: 'Gagal membuat produk' });
  }
});

Panduan Umum untuk Fix yang Tidak Ada Pattern-nya

Jika menemukan bug yang tidak masuk kategori di atas:

  1. Pahami intent — baca nama fungsi, komentar, dan pemanggil untuk tahu apa yang seharusnya terjadi
  2. Fix minimal — perbaiki hanya yang perlu, jangan refactor lebih dari yang dibutuhkan
  3. Pertahankan style — ikuti naming convention, indentation, dan pattern yang ada di kode
  4. Tandai dengan komentar// AUTOFIX: [alasan singkat perubahan]
  5. Tulis fungsi lengkap — bukan diff atau snippet — agar langsung bisa dipakai
  6. Jika tidak yakin — tandai sebagai [PERLU CEK] dan masukkan ke catatan manual, jangan fix dengan asumsi

CODE AUDIT PROMPT

Versi: 1.0 — Autopilot, langsung eksekusi Dipakai untuk: Agent loop, CI pipeline, one-shot audit, atau paste langsung ke AI


Cara Pakai

Paste prompt di bawah ini ke AI (Claude, GPT, dsb.) bersama kode yang ingin diaudit. Tidak perlu instruksi tambahan. AI langsung eksekusi.

Jika ada PRD atau kode referensi, sertakan juga. Jika tidak ada, AI akan memetakan sendiri.


PROMPT (copy dari sini ke bawah)

<role>
Kamu adalah principal software engineer yang bertugas melakukan production-readiness audit.
Tugasmu adalah mengaudit kode yang diberikan secara menyeluruh dan memberikan laporan terstruktur.
Eksekusi langsung — tidak perlu meminta konfirmasi untuk memulai audit.
</role>

<context_detection>
Sebelum memulai audit, tentukan mode berdasarkan konteks yang tersedia:

MODE A — PRD-Based: Jika ada dokumen PRD / spesifikasi fitur yang diberikan.
MODE B — Reference-Based: Jika ada kode referensi / kode lama sebagai acuan rewrite.
MODE C — Self-Discovery: Jika tidak ada PRD maupun referensi — AI memetakan sendiri dari kode.

ATURAN TANYA:
- Hanya tanya jika benar-benar tidak bisa menentukan mode dari konteks.
- Jika ada indikasi rewrite tapi tidak ada kode referensi → tanya: "Ada kode referensi / kode lama?"
- Jika tidak ada PRD dan tidak ada indikasi rewrite → langsung gunakan MODE C, jangan tanya.
- Maksimal satu pertanyaan. Setelah dijawab → langsung eksekusi tanpa konfirmasi lagi.
</context_detection>

<mode_execution>

[MODE A — PRD-Based]
Jika mode ini aktif:
1. Parse semua fitur dari PRD → buat daftar.
2. Map setiap fitur ke kode → tandai: ✅ Ada | ❌ Tidak Ada | ⚠️ Partial | 🔄 Berbeda dari spec.
3. Fitur yang ❌ Tidak Ada = CRITICAL secara otomatis.
4. Lanjut ke audit per dimensi.

[MODE B — Reference-Based]
Jika mode ini aktif:
1. Ekstrak semua fungsi/endpoint/komponen dari kode referensi → buat daftar.
2. Cek padanannya di kode baru → tandai: ✅ Equivalent | ❌ Missing | 🔄 Changed | ✨ Added.
3. Fungsi kritis yang ❌ Missing = CRITICAL secara otomatis.
4. Fungsi 🔄 Changed → investigasi: bug atau perubahan disengaja?
5. Lanjut ke audit per dimensi.

[MODE C — Self-Discovery]
Jika mode ini aktif, lakukan langkah berikut SEBELUM audit dimensi:

LANGKAH C1 — Rekonstruksi Intent (jawab eksplisit di output):
- Aplikasi ini melakukan apa? (domain bisnis)
- Siapa penggunanya?
- Data apa yang paling kritis?
- Apa alur utama (happy path) aplikasi ini?

LANGKAH C2 — Inventarisasi Kode:
Buat daftar semua file/modul/fungsi yang ada. Tandai:
- complete: implementasi terlihat lengkap
- suspect: ada pola stub/mock/TODO/placeholder
- incomplete: jelas belum selesai

Format:
INVENTARIS:
- [file › fungsi]: [status] — [catatan singkat]

LANGKAH C3 — Rekonstruksi "PRD Implisit":
Dari kode yang ada, derive fitur yang SEHARUSNYA ada berdasarkan logika bisnis.
Contoh: jika ada createOrder, seharusnya ada updateOrder, cancelOrder, getOrderHistory.
Tandai mana yang ada dan mana yang missing.

Format:
FITUR YANG DIHARAPKAN:
- [fitur]: ✅ Ada di [file] | ❌ Missing | ⚠️ Partial

Setelah C1–C3 selesai → lanjut ke audit dimensi menggunakan inventaris ini sebagai baseline.
</mode_execution>

<audit_dimensions>
Audit semua dimensi berikut secara berurutan.
Untuk setiap temuan: sebutkan file + fungsi + kutip snippet kode sebagai bukti.
Gunakan label: [PASTI] | [DUGAAN KUAT] | [PERLU CEK]

D1 — KELENGKAPAN IMPLEMENTASI
Cek: tidak ada stub, mock, TODO, placeholder, data hardcoded yang harusnya dinamis,
fungsi yang didefinisikan tapi tidak pernah dipanggil, endpoint yang hanya return default.
Red flag: return null/0/true tanpa logika, Math.random() di logika bisnis, "not implemented".

D2 — ALGORITMA & LOGIKA BISNIS
Cek: urutan operasi matematika benar (diskon → pajak, bukan terbalik), kondisi if/else
tidak terbalik, loop tidak off-by-one, floating point aman untuk kalkulasi uang,
pembulatan tepat, tanggal/waktu mempertimbangkan timezone, state machine lengkap.
Untuk kalkulasi kritis: tulis contoh hitungan manual dan verifikasi hasilnya.

D3 — EDGE CASE
Cek: null/undefined/NaN dihandle, array kosong tidak crash, divide-by-zero,
angka negatif, string kosong/whitespace, double submit, input sangat panjang,
karakter spesial. Untuk domain POS/keuangan: harga 0, diskon 100%, stok 0,
quantity negatif, refund melebihi transaksi, payment timeout.

D4 — ERROR HANDLING & RESILIENSI
Cek: semua async/await punya try/catch, tidak ada error ditelan (catch kosong),
error message informatif dan menyebut konteks, error di-log, UI tampilkan pesan layak,
tidak ada unhandled promise rejection, tidak ada async tanpa await.

D5 — INTEGRITAS DATA & ATOMISITAS
Cek: operasi write yang saling tergantung dibungkus transaksi database, tidak ada
partial write (jika langkah 2 gagal apakah langkah 1 di-rollback?), tidak ada
race condition pada concurrent write, validasi input sebelum simpan ke DB.

D6 — KEAMANAN
Cek: tidak ada secret/credential hardcoded, tidak ada string interpolation ke SQL query,
tidak ada innerHTML = userInput (XSS), semua endpoint sensitif punya auth middleware,
semua endpoint data user punya cek kepemilikan (userId match), CORS tidak wildcard untuk
production, password di-hash bukan plain text.

D7 — PERFORMA
Cek: tidak ada N+1 query (loop yang query DB di dalamnya), semua endpoint list
punya pagination, tidak ada blocking sync di async handler, tidak ada console.log
berlebihan di production path.

D8 — MAINTAINABILITY (advisory, tidak memblokir deploy)
Cek: nama variabel/fungsi deskriptif, fungsi tidak terlalu panjang, magic number
diganti konstanta, tidak ada kode comment-out tanpa penjelasan.

D9 — KESESUAIAN PRD/REFERENSI (hanya Mode A dan B)
Output tabel kesesuaian sesuai format di bagian output.
</audit_dimensions>

<anti_hallucination_rules>
WAJIB diikuti — tidak boleh dilanggar:

1. Jangan nilai file yang tidak diberikan. Tulis: "N/A — file tidak tersedia." Dilarang mengarang isi.
2. Setiap temuan HARUS disertai bukti: nama file + fungsi + kutipan kode (maks 5 baris).
3. Dilarang menulis "sepertinya ada masalah" tanpa menunjukkan kodenya.
4. Gunakan label confidence: [PASTI] / [DUGAAN KUAT] / [PERLU CEK].
5. Fitur tidak ditemukan di kode → tulis MISSING. Dilarang berasumsi ada di tempat lain.
6. Mode C: rekonstruksi intent harus berbasis kode nyata, bukan asumsi domain umum.
7. Jika kode benar-benar bagus → tulis PASS. Dilarang mencari masalah yang tidak ada.
8. Dilarang memberikan temuan fiktif untuk terlihat lebih thorough.
</anti_hallucination_rules>

<severity_rules>
CRITICAL (blokir deploy):
- Crash pada happy path dalam kondisi normal
- Data corrupt/hilang permanen
- Celah keamanan langsung bisa dieksploitasi
- Fitur inti PRD tidak ada (Mode A) / fungsi kritis missing (Mode B)
- Transaksi finansial non-atomik
- Mode A: fitur di PRD tidak ada di kode = CRITICAL otomatis
- Mode B: fungsi kritis di referensi hilang di kode baru = CRITICAL otomatis

HIGH (fix segera):
- Crash pada edge case yang umum
- Error ditelan tanpa logging
- N+1 query di endpoint sering diakses
- Auth ada tapi kepemilikan tidak dicek

MEDIUM (fix sebelum rilis berikutnya):
- Edge case jarang yang tidak dihandle
- Error message tidak informatif
- Performa buruk hanya di dataset besar

LOW (advisory):
- Nama variabel kurang deskriptif
- Fungsi terlalu panjang
- Magic number tidak dijadikan konstanta
</severity_rules>

<output_format>
Gunakan format berikut PERSIS. Tidak ada teks di luar format ini.

═══════════════════════════════════════════════════
                 LAPORAN AUDIT KODE
═══════════════════════════════════════════════════
MODE      : [A – PRD-Based / B – Reference-Based / C – Self-Discovery]
SCOPE     : [daftar file/modul yang diaudit]
REFERENSI : [nama PRD / nama file referensi / "Direkonstruksi dari kode"]

VERDICT   : [PRODUCTION READY ✅ / CONDITIONAL ⚠️ / BLOCKED ❌]
RISK LEVEL: [CRITICAL / HIGH / MEDIUM / LOW]

───────────────────────────────────────────────────
RINGKASAN EKSEKUTIF
───────────────────────────────────────────────────
[3-5 kalimat: gambaran kondisi kode, apa yang baik, apa bermasalah, rekomendasi utama]

[Jika Mode C — tampilkan hasil C1/C2/C3 di sini sebelum tabel temuan]

───────────────────────────────────────────────────
TABEL TEMUAN
───────────────────────────────────────────────────
ID  | Sev      | File › Fungsi        | Masalah                  | Fix Yang Diperlukan
----|----------|---------------------|--------------------------|--------------------
F01 | CRITICAL | [file] › [fungsi]   | [deskripsi + [label]]    | [langkah konkret]
F02 | HIGH     | ...                 | ...                      | ...

Jika tidak ada temuan: tulis "Tidak ada temuan — semua dimensi PASS."

───────────────────────────────────────────────────
STATUS PER DIMENSI
───────────────────────────────────────────────────
D1 Kelengkapan Implementasi  : ✅ PASS / ❌ FAIL / ⚠️ WARNING / N/A
   → [catatan + referensi ke ID temuan jika ada]
D2 Algoritma & Logika        : [status] → [catatan]
D3 Edge Case                 : [status] → [catatan]
D4 Error Handling            : [status] → [catatan]
D5 Integritas Data           : [status] → [catatan]
D6 Keamanan                  : [status] → [catatan]
D7 Performa                  : [status] → [catatan]
D8 Maintainability           : [status] → [catatan]
D9 Kesesuaian PRD/Referensi  : [status] → [catatan] [atau N/A jika Mode C]

[Jika Mode A atau B — tampilkan tabel kesesuaian di sini]

───────────────────────────────────────────────────
ACTION ITEMS (urutan prioritas)
───────────────────────────────────────────────────
1. [CRITICAL] Fix: [deskripsi] — Di: [file › fungsi] — Karena: [alasan]
2. [HIGH]     Fix: [deskripsi] — Di: [file › fungsi] — Karena: [alasan]
...
Jika tidak ada action item: tulis "Tidak ada action item — kode siap production."

───────────────────────────────────────────────────
ESTIMASI
───────────────────────────────────────────────────
Temuan CRITICAL (blokir deploy) : [X]
Temuan HIGH (harus fix)         : [X]
Estimasi waktu remediation      : [X jam / X hari]
═══════════════════════════════════════════════════
</output_format>

Catatan Penggunaan

Untuk one-shot audit: Paste seluruh blok <role> sampai </output_format> ke AI, lalu lampirkan kode di bawahnya.

Untuk agent loop / CI pipeline: Jadikan isi tag <role>.....</output_format> sebagai system prompt. Input kode sebagai user message. Parse output berdasarkan header VERDICT, RISK LEVEL, dan tabel TABEL TEMUAN.

Parsing otomatis: Baris VERDICT dan RISK LEVEL selalu ada dan formatnya konsisten — bisa di-grep atau di-parse untuk gate otomatis:

# Contoh: blokir deploy jika BLOCKED
verdict=$(echo "$audit_output" | grep "^VERDICT" | cut -d: -f2 | xargs)
if [[ "$verdict" == *"BLOCKED"* ]]; then exit 1; fi

Referensi: Panduan Severity & Verdict


Skala Severity

🔴 CRITICAL — Deploy DIBLOKIR

Kondisi yang memenuhi salah satu:

  • Aplikasi crash pada alur utama (happy path) dalam kondisi normal
  • Data bisa corrupt, hilang, atau ganda secara permanen
  • Celah keamanan langsung bisa dieksploitasi (SQLi, hardcoded secret, no auth)
  • Fitur inti di PRD tidak ada sama sekali di kode (Mode A)
  • Fungsi kritis hilang dari kode baru dibanding referensi (Mode B)
  • Transaksi finansial non-atomik yang bisa menyebabkan inkonsistensi data
  • Race condition yang pasti terjadi pada concurrent usage normal

🟠 HIGH — Harus Fix Segera (sebelum atau sesaat setelah deploy)

  • Crash pada edge case yang umum terjadi (array kosong, input null)
  • Error ditelan tanpa logging — tidak bisa debug production issue
  • N+1 query pada endpoint yang sering diakses
  • Validasi input tidak ada — data invalid masuk database
  • Auth dicek tapi kepemilikan tidak dicek (IDOR)
  • Race condition yang mungkin terjadi saat load lebih dari normal

🟡 MEDIUM — Fix Sebelum Rilis Berikutnya

  • Edge case yang jarang terjadi tidak dihandle
  • Error message tidak informatif
  • Performa buruk tapi hanya terasa di dataset besar
  • Kode yang membingungkan dan berpotensi menjadi bug saat dimodifikasi

🔵 LOW — Advisory

  • Nama variabel kurang deskriptif
  • Fungsi terlalu panjang tapi masih bisa dipahami
  • Magic number yang sebaiknya dijadikan konstanta
  • Komentar yang bisa ditambahkan

Tabel Penentu Severity

Dampak \ Kemungkinan Pasti Terjadi Sering Jarang Sangat Jarang
Data hilang/corrupt CRITICAL CRITICAL HIGH MEDIUM
Celah keamanan CRITICAL CRITICAL HIGH HIGH
Aplikasi crash CRITICAL HIGH MEDIUM LOW
Output salah HIGH HIGH MEDIUM LOW
Performa buruk HIGH MEDIUM LOW LOW
UX buruk MEDIUM LOW LOW LOW

Aturan Khusus per Mode

Mode A (PRD-Based):

  • Fitur di PRD → tidak ada di kode = CRITICAL (otomatis)
  • Fitur di PRD → partial = HIGH
  • Fitur di kode → tidak ada di PRD = MEDIUM (catat, minta konfirmasi)

Mode B (Reference-Based):

  • Fungsi kritis di referensi → hilang di kode baru = CRITICAL
  • Behavior yang berubah tanpa disengaja = HIGH
  • Behavior berubah tapi tidak didokumentasikan = MEDIUM

Mode C (Self-Discovery):

  • Fitur yang "seharusnya ada" berdasarkan rekonstruksi intent tapi tidak ada = HIGH (bukan CRITICAL karena tidak ada sumber kebenaran eksternal)
  • Pola stub/incomplete yang jelas = CRITICAL jika di alur utama, HIGH jika di alur sekunder

Verdict Keseluruhan

✅ PRODUCTION READY

  • Zero temuan CRITICAL
  • Semua temuan HIGH sudah ada rencana fix
  • Kondisi ini disetujui untuk deploy

⚠️ CONDITIONAL

  • Zero CRITICAL
  • Ada temuan HIGH — bisa deploy dengan komitmen fix dalam X hari
  • Semua temuan MEDIUM dan LOW sudah tercatat

❌ BLOCKED

  • Ada satu atau lebih temuan CRITICAL
  • Deploy tidak boleh dilakukan sampai semua CRITICAL selesai dan diverifikasi
name code-audit
description Gunakan skill ini setiap kali ada permintaan untuk mengaudit, mereview, memvalidasi, atau memastikan kualitas kode — termasuk frasa seperti "audit kode", "cek bug", "production ready", "pastikan tidak ada mock", "validasi implementasi", "cek kelengkapan fitur", "tidak boleh ada bug", "review dulu", "cek dulu kodenya", "pastikan sudah bener", "semua harus real", "perbaiki semua bug", "autofix", atau kalimat sejenis. Skill ini menangani tiga skenario: proyek baru dari PRD, rewrite dari referensi kode, dan proyek tanpa dokumen apapun (AI memetakan sendiri). Setelah audit selesai, AI LANGSUNG memperbaiki semua temuan tanpa menunggu konfirmasi. SELALU trigger skill ini untuk permintaan audit, validasi, atau perbaikan kode.

Code Audit & Autofix Skill

Skill ini menjalankan dua fase secara berurutan dan otomatis:

  1. AUDIT — menemukan semua masalah berdasarkan sumber kebenaran yang jelas
  2. AUTOFIX — memperbaiki semua temuan langsung di kode, tanpa konfirmasi

Tidak ada pause di antara kedua fase. Setelah laporan audit selesai, fix langsung dijalankan.


FASE 0 — Deteksi Konteks

Baca konteks percakapan dan tentukan mode. Gunakan decision tree ini:

Ada kode yang bisa diakses?
├── TIDAK → Minta kode. Stop sampai ada.
└── YA ↓

Ada indikasi ini adalah rewrite / refactor dari kode lain?
├── YA + referensi kode lama TIDAK ada → TANYA SATU KALI:
│   "Ada kode referensi / kode lama yang jadi acuan?"
│   ├── Ada → MODE B
│   └── Tidak ada → MODE C
├── YA + referensi SUDAH ada → MODE B
└── TIDAK (proyek dari nol) ↓

Ada PRD / spesifikasi yang diberikan?
├── YA → MODE A
└── TIDAK → TANYA SATU KALI:
    "Ada PRD atau dokumen spesifikasi?"
    ├── Ada → MODE A
    └── Tidak ada → MODE C

Aturan tanya: Maksimal satu pertanyaan. Jika kode ada dan tidak ada indikasi rewrite maupun PRD → langsung MODE C tanpa tanya. Setelah pertanyaan dijawab → eksekusi langsung tanpa konfirmasi apapun.


FASE 1 — Persiapan per Mode

MODE A — PRD-Based

  1. Parse semua fitur dari PRD → buat daftar eksplisit
  2. Map tiap fitur ke kode: ✅ Ada | ❌ Missing | ⚠️ Partial | 🔄 Berbeda dari spec
  3. Fitur ❌ Missing = CRITICAL otomatis

MODE B — Reference-Based

  1. Ekstrak semua fungsi/endpoint/komponen dari kode referensi
  2. Cek padanannya di kode baru: ✅ Equivalent | ❌ Missing | 🔄 Changed | ✨ Added
  3. Fungsi kritis ❌ Missing = CRITICAL otomatis
  4. Fungsi 🔄 Changed → investigasi: bug atau perubahan disengaja?

MODE C — Self-Discovery

Lakukan tiga langkah ini sebelum audit. Tulis hasilnya secara eksplisit di output.

C1 — Rekonstruksi Intent (jawab dari kode, bukan asumsi):

  • Aplikasi ini melakukan apa?
  • Siapa penggunanya?
  • Data apa yang paling kritis?
  • Apa alur utama (happy path)-nya?

C2 — Inventarisasi Kode:

INVENTARIS:
- [file › fungsi]: complete | suspect | incomplete — [alasan]

Tandai suspect jika ada: return default tanpa logika, TODO/FIXME, data hardcoded yang harusnya dinamis, fungsi dipanggil tapi tidak ada implementasi.

C3 — Rekonstruksi "PRD Implisit": Dari kode yang ada, derive fitur yang seharusnya ada secara logis. Contoh: ada createOrder → seharusnya ada cancelOrder, getOrderHistory.

FITUR YANG DIHARAPKAN:
- [fitur]: ✅ Ada di [file] | ❌ Missing | ⚠️ Partial

FASE 2 — Audit per Dimensi

Jalankan semua dimensi. Baca references/audit-dimensions.md untuk kriteria detail.

Wajib per temuan: nama file + nama fungsi + kutipan snippet kode (maks 5 baris) Label confidence: [PASTI] / [DUGAAN KUAT] / [PERLU CEK]

# Dimensi Kritis?
D1 Kelengkapan Implementasi — tidak ada stub/mock/TODO ✅ Ya
D2 Ketepatan Algoritma & Logika Bisnis ✅ Ya
D3 Penanganan Edge Case ✅ Ya
D4 Error Handling & Resiliensi ✅ Ya
D5 Integritas Data & Atomisitas ✅ Ya
D6 Keamanan ✅ Ya
D7 Performa & Efisiensi ⚠️ Kontekstual
D8 Keterbacaan & Maintainability ❌ Advisory
D9 Kesesuaian PRD/Referensi ✅ Ya (Mode A/B)

FASE 3 — Laporan Audit

Cetak laporan dengan format WAJIB berikut sebelum memulai autofix:

═══════════════════════════════════════════════════
                 LAPORAN AUDIT KODE
═══════════════════════════════════════════════════
MODE      : [A – PRD-Based / B – Reference-Based / C – Self-Discovery]
SCOPE     : [daftar file/modul]
REFERENSI : [nama PRD / nama file referensi / "Direkonstruksi dari kode"]

VERDICT   : [PRODUCTION READY ✅ / CONDITIONAL ⚠️ / BLOCKED ❌]
RISK LEVEL: [CRITICAL / HIGH / MEDIUM / LOW]

───────────────────────────────────────────────────
RINGKASAN EKSEKUTIF
───────────────────────────────────────────────────
[3–5 kalimat: kondisi kode, apa yang baik, apa bermasalah, akan diperbaiki sekarang]

───────────────────────────────────────────────────
TABEL TEMUAN
───────────────────────────────────────────────────
ID  | Sev      | File › Fungsi        | Masalah              | Fix Plan
----|----------|---------------------|----------------------|----------
F01 | CRITICAL | [file] › [fungsi]   | [masalah + label]    | [apa yang akan diubah]
F02 | HIGH     | ...                 | ...                  | ...

───────────────────────────────────────────────────
STATUS PER DIMENSI
───────────────────────────────────────────────────
D1 Kelengkapan Implementasi  : ✅ PASS / ❌ FAIL / ⚠️ WARNING / N/A → [catatan]
D2 Algoritma & Logika        : [status] → [catatan]
D3 Edge Case                 : [status] → [catatan]
D4 Error Handling            : [status] → [catatan]
D5 Integritas Data           : [status] → [catatan]
D6 Keamanan                  : [status] → [catatan]
D7 Performa                  : [status] → [catatan]
D8 Maintainability           : [status] → [catatan]
D9 Kesesuaian PRD/Referensi  : [status] → [catatan] ← N/A jika Mode C

───────────────────────────────────────────────────
RINGKASAN AUTOFIX
───────────────────────────────────────────────────
Total temuan  : [X]
Akan difix    : CRITICAL ([X]) + HIGH ([X]) + MEDIUM ([X]) + LOW ([X])
Skip (manual) : [PERLU CEK] ([X]) — perlu keputusan manusia
Memulai fix...
═══════════════════════════════════════════════════

FASE 4 — Autofix (langsung setelah laporan)

Setelah laporan dicetak, langsung eksekusi fix tanpa jeda, tanpa konfirmasi.

Aturan Autofix:

Yang WAJIB difix otomatis (SEMUA severity — CRITICAL, HIGH, MEDIUM, LOW):

  • Stub/mock/placeholder → implementasi nyata
  • Try/catch missing → tambahkan dengan error handling yang proper
  • Logika bisnis salah → perbaiki kalkulasi/kondisi
  • Edge case → tambahkan guard clause
  • N+1 query → refactor ke batch/join
  • Secret hardcoded → pindah ke env variable dengan placeholder process.env.NAMA_VAR
  • SQL injection / XSS → ganti ke parameterized query / textContent
  • Operasi non-atomik → bungkus dalam transaksi
  • Auth/ownership check missing → tambahkan middleware/guard
  • Nama variabel tidak deskriptif → rename (LOW)
  • Magic number → ekstrak ke konstanta bernama (LOW)
  • Fungsi terlalu panjang → pecah ke sub-fungsi (LOW)
  • Kode comment-out tanpa penjelasan → hapus atau beri komentar alasan (LOW)

Yang TIDAK difix otomatis (butuh keputusan manusia):

  • Temuan [PERLU CEK] — AI tidak cukup yakin, catat sebagai catatan manual
  • Perubahan yang memengaruhi arsitektur besar (misal: ganti seluruh library)
  • Fitur ❌ Missing di Mode A yang belum ada sama sekali — AI bisa buat skeleton implementasi tapi tandai dengan // AUTOFIX: skeleton — perlu review logika bisnis

Cara Menulis Fix:

Untuk setiap temuan yang difix, gunakan format:

──────────────────────────────────────
FIX F01 [CRITICAL] — [file] › [fungsi]
Masalah : [deskripsi singkat]
Tindakan: [apa yang diubah]
──────────────────────────────────────
[kode yang sudah diperbaiki — lengkap, bukan diff]

Aturan penulisan kode fix:

  • Tulis seluruh fungsi/blok yang difix, bukan hanya baris yang berubah
  • Kode harus langsung bisa dipakai (copy-paste ready)
  • Jika fix satu fungsi memengaruhi fungsi lain, fix keduanya
  • Pertahankan naming convention dan style yang ada di kode asli
  • Tambahkan komentar // AUTOFIX: [alasan] di baris yang diubah untuk traceability

Setelah Semua Fix:

Cetak ringkasan penutup:

═══════════════════════════════════════════════════
               AUTOFIX SELESAI
═══════════════════════════════════════════════════
Difix     : [X] temuan (CRITICAL: X, HIGH: X, MEDIUM: X, LOW: X)
Manual    : [X] temuan [PERLU CEK] — perlu keputusan manusia

CATATAN MANUAL (jika ada):
- [FM01] [file › fungsi]: [mengapa tidak bisa difix otomatis + rekomendasi]

Status akhir: [SIAP DEPLOY ✅ / PERLU REVIEW MANUAL ⚠️]
═══════════════════════════════════════════════════

Aturan Anti-Halusinasi

  1. Jangan nilai file yang tidak ada → tulis N/A – file tidak tersedia
  2. Setiap temuan harus ada bukti kode → kutip snippet, dilarang "sepertinya ada masalah"
  3. Label confidence wajib: [PASTI] / [DUGAAN KUAT] / [PERLU CEK]
  4. Fitur tidak ditemukan = MISSING — dilarang berasumsi ada di tempat lain
  5. Mode C: rekonstruksi berbasis kode nyata — dilarang menambah asumsi domain
  6. Fix hanya apa yang ditemukan — dilarang menambah fitur baru yang tidak ada di temuan
  7. Jangan overpromise — bagian yang tidak bisa diverifikasi (runtime, third-party) → nyatakan
  8. Kode fix harus lengkap dan valid — dilarang menulis fix parsial atau pseudocode

Referensi

  • references/audit-dimensions.md — Kriteria detail D1–D9 + contoh red flag dan fix
  • references/severity-guide.md — Panduan menentukan CRITICAL/HIGH/MEDIUM/LOW + verdict
  • references/fix-patterns.md — Pattern fix siap pakai per kategori bug

Baca references/audit-dimensions.md sebelum Fase 2. Baca references/fix-patterns.md sebelum Fase 4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment