Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions .docs/AGENTS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# .docs/ -- Engineering Documentation Center

## Fungsi

Pusat dokumentasi internal engineering: architecture decisions, technical guides, design docs, testing strategy, deployment, security, AI collaboration.

## Aturan Penggunaan

- Baca dokumentasi yang relevan SEBELUM memulai task baru
- Update dokumentasi SETELAH ada keputusan atau perubahan berarti
- Bahasa Indonesia wajib untuk semua dokumentasi

## Struktur

| Folder | Isi |
| ------------- | ----------------------------------- |
| product/ | Visi produk, roadmap, feature specs |
| design/ | Design system, UI/UX guidelines |
| technical/ | Tech stack, dependencies |
| engineering/ | Coding standards, workflow |
| architecture/ | System architecture, data flow |
| adr/ | Architecture Decision Records |
| api/ | API documentation |
| testing/ | Testing strategy |
| deployment/ | Deployment pipeline |
| security/ | Security policies |
| ai/ | AI agent collaboration |
| onboarding/ | Developer onboarding |
| glossary/ | Terminology |

## Best Practices

- Setiap folder memiliki README.md dengan template
- ADR untuk keputusan arsitektur penting
- Dokumentasi sifatnya living document

## AI Do's / Don'ts

- Boleh: membaca .docs/ sebelum task, mengupdate dokumentasi
- Tidak boleh: menghapus dokumentasi tanpa deprecation notice
- Wajib: baca .docs/ai/ sebelum berinteraksi dengan project
87 changes: 87 additions & 0 deletions .docs/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# .docs -- Pusat Dokumentasi Engineering

> Dokumentasi internal untuk pengembangan project ini.
> Bukan dokumentasi user -- ini adalah **engineering knowledge base**.

---

## Tujuan

Folder `.docs` adalah pusat dokumentasi engineering yang berfungsi sebagai:

- **Single source of truth** untuk keputusan teknis dan arsitektur
- **Knowledge base** untuk developer dan AI agent
- **Onboarding hub** untuk anggota tim baru
- **Decision log** untuk mencatat why di balik setiap keputusan

---

## Struktur Folder

| Folder | Fungsi |
| --------------- | -------------------------------------------------------- |
| `product/` | Visi produk, roadmap, user stories, feature specs |
| `design/` | Design system, UI/UX guidelines, component patterns |
| `technical/` | Tech stack, dependencies, konfigurasi, development setup |
| `engineering/` | Engineering practices, code review, coding standards |
| `architecture/` | System architecture, data flow, module boundaries |
| `adr/` | Architecture Decision Records -- keputusan arsitektur |
| `api/` | API documentation, endpoint specs, request/response |
| `testing/` | Testing strategy, test types, coverage goals |
| `deployment/` | Deployment pipeline, environments, infrastructure |
| `security/` | Security policies, auth, authorization, data protection |
| `ai/` | AI agent collaboration guide, prompt conventions |
| `onboarding/` | New developer onboarding, setup guide |
| `glossary/` | Project terminology, abbreviations, definitions |

---

## Cara Menggunakan

1. **Baca dulu** -- cek folder yang relevan sebelum memulai task baru
2. **Update secara berkala** -- tambahkan insight, keputusan, dan pelajaran baru
3. **Jangan hapus** -- dokumentasi adalah aset. Deprecate, jangan delete
4. **Gunakan template** -- setiap folder menyediakan template untuk konsistensi
5. **Bahasa Indonesia** -- semua dokumentasi wajib Bahasa Indonesia (kecuali kode)

---

## Prinsip Penulisan

| Prinsip | Penjelasan |
| ---------------- | ------------------------------------------------------- |
| **Professional** | Hindari bahasa informal, emoji, atau subjective opinion |
| **Clear** | Jelaskan konteks, bukan hanya apa yang terjadi |
| **Practical** | Berikan contoh nyata, bukan teori abstrak |
| **Up-to-date** | Jika informasi berubah, update dokumentasi |
| **Searchable** | Gunakan judul dan struktur yang mudah dicari |

---

## Format Dokumen

Setiap dokumen sebaiknya memiliki struktur:

```markdown
# Judul Dokumen

## Tujuan

[Mengapa dokumen ini dibuat]

## Konteks

[Latar belakang, keputusan yang melatarbelakangi]

## Isi

[Konten utama]

## Referensi

[Link ke dokumen terkait]
```

---

_Dokumentasi adalah investasi. Setiap menit yang dihabiskan untuk menulis docs menghemat berjam-jam kebingungan di masa depan._
125 changes: 125 additions & 0 deletions .docs/adr/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,125 @@
# adr/ -- Architecture Decision Records

> Mencatat keputusan arsitektur penting beserta konteks dan konsekuensinya.

---

## Tujuan

ADR (Architecture Decision Record) adalah dokumentasi **keputusan arsitektur** yang mencakup:

- Konteks mengapa keputusan diambil
- Alternatif yang dipertimbangkan
- Keputusan final yang diambil
- Konsekuensi dari keputusan tersebut
- Status keputusan (proposed, accepted, deprecated, superseded)

---

## Format ADR (Y-Statements)

Setiap ADR menggunakan format **Y-Statement**:

```markdown
# ADR-[nomor]: [Judul Keputusan]

## Status

[Proposed | Accepted | Deprecated | Superseded by ADR-NNN]

## Context

[Jelaskan konteks dan problem yang mendorong keputusan ini]

## Decision

[Gunakan format "We will..." atau "Kami memutuskan untuk..."]

## Rationale

[Jelaskan alasan di balik keputusan]

## Consequences

### Positive

- [Dampak positif]

### Negative

- [Dampak negatif]

### Neutral

- [Dampak netral]

## Alternatives Considered

### Alternative 1: [Nama]

- Pros: ...
- Cons: ...

### Alternative 2: [Nama]

- Pros: ...
- Cons: ...

## References

- [Link ke dokumentasi terkait]
- [Link ke issue/PR]
```

---

## Template ADR (Simple)

```markdown
# ADR-001: [Judul]

**Status:** Proposed

**Context:**
[Problem dan latar belakang]

**Decision:**
Kami akan [keputusan]

**Rationale:**
[Alasan]

**Consequences:**

- Positif: [...]
- Negatif: [...]

**Alternatives:**

1. [Alternatif 1] -- ditolak karena [...]
2. [Alternatif 2] -- ditolak karena [...]
```

---

## Kapan Harus Membuat ADR

Buat ADR ketika:

- Mengadopsi teknologi/library baru
- Mengubah struktur folder atau arsitektur
- Memutuskan design pattern yang signifikan
- Mengubah data model atau schema
- Memutuskan strategi caching, state management, API design
- Mengubah konfigurasi infrastruktur

---

## Best Practices

1. **Buat sebelum implementasi** -- ADR adalah keputusan, bukan catatan setelah coding
2. **Satu ADR per keputusan** -- Jangan campur beberapa keputusan dalam satu ADR
3. **Nomor berurutan** -- ADR-001, ADR-002, dst.
4. **Immutable setelah accepted** -- Jika berubah, buat ADR baru yang supersede
5. **Kaitkan dengan kode** -- Referensikan ADR di commit messages dan PR descriptions
6. **Review berkala** -- Pastikan ADR yang deprecated ditandai dengan jelas
83 changes: 83 additions & 0 deletions .docs/adr/adr-001-product-pivot-contribution-hub.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
# ADR-001: Product Pivot ke Contribution Hub

## Status

**Accepted**

## Context

Project ini awalnya dimulai sebagai starter foundation project untuk Next.js 16 dengan FSD architecture. ROADMAP.md sebelumnya menyebutkan visi sebagai "platform referensi film modern." Namun, setelah evaluasi lebih lanjut, beberapa faktor mendorong perubahan arah:

1. **Market terlalu kompetitif** untuk platform referensi film (TMDB, IMDb, MyDramaList sudah dominan)
2. **Tidak ada diferensiasi kuat** yang bisa dibangun di area tersebut dengan sumber daya terbatas
3. **Tim/Founder memiliki latar belakang dan passion di developer tooling**
4. **Kebutuhan nyata** di ekosistem developer Indonesia: tools untuk membantu konsistensi coding dan dokumentasi progress
5. **Foundation project sudah solid** secara teknis dan bisa diarahkan ke domain apapun

## Decision

Kami memutuskan untuk mengubah arah produk dari "platform referensi film" menjadi **Contribution Hub: Developer Activity Assistant**.

## Rationale

1. **Market need validation**: Banyak developer Indonesia mengalami masalah konsistensi coding, dokumentasi progress, dan personal branding di GitHub. Produk ini menyelesaikan masalah nyata.

2. **Teknologi alignment**: Tech stack yang sudah ada (Next.js, React Query, Zustand, Zod) sangat cocok untuk membangun developer tooling. GitHub API integration adalah use case yang natural.

3. **Differentiation**: Tidak ada produk Indonesia yang secara spesifik membahas "developer activity assistant" dengan fokus pada meaningful contribution.

4. **Scalability**: Produk bisa tumbuh dari personal tool ke team platform ke ecosystem.

5. **Developer empathy**: Kami memahami masalah ini karena kami juga mengalaminya sebagai developer.

6. **Foundation preservation**: Struktur FSD, coding standards, dan dokumentasi yang sudah dibangun tetap relevan dan bisa digunakan langsung.

## Consequences

### Positive

- Market niche yang jelas dan underserved
- Developer tooling memiliki recurring usage pattern (harian)
- Potensi community building yang kuat (developer-centric)
- Teknologi stack yang ada sangat cocok
- Bisa dimonetisasi dengan freemium model yang jelas

### Negative

- Target pasar lebih kecil dibanding platform referensi film
- Membutuhkan integrasi dengan GitHub API (dependency eksternal)
- Developer tools butuh trust building yang lebih lama
- Kompetisi dengan tools internasional (WakaTime, GitClear)

### Neutral

- Nama project (next-app) dan domain perlu diubah
- Dokumentasi produk harus ditulis ulang (dilakukan di ADR ini)
- Branding perlu dibangun dari awal

## Alternatives Considered

### Alternative 1: Tetap dengan platform referensi film

- Pros: Market besar, banyak yang bisa dipelajari
- Cons: Kompetisi ketat, tidak ada diferensiasi, butuh data konten yang besar
- **Ditolak** karena tidak ada competitive advantage

### Alternative 2: Productivity tool general

- Pros: Market sangat luas
- Cons: Terlalu generic, susah positioning, banyak kompetitor
- **Ditolak** karena terlalu broad

### Alternative 3: Coding bootcamp platform

- Pros: Tren edtech sedang naik
- Cons: Butuh konten edukasi, operasional berat, business model kompleks
- **Ditolak** karena terlalu berat untuk solo developer

## References

- [Product Definition](../product/definition.md)
- [Product Vision](../product/vision.md)
- [Product Roadmap](../product/roadmap.md)
- [ADR-002: Meaningful Contribution Philosophy](./adr-002-meaningful-contribution-philosophy.md)
Loading
Loading