git:20260729.c8863c0 to git:20260809.9101e26

---

name: auto-doc-updater

description: "Automatically documents every feature change or bug fix successfully built into CHANGELOG.md and BLUEPRINT.md / Otomatis mendokumentasikan setiap perubahan fitur atau perbaikan bug yang berhasil di-build ke CHANGELOG.md dan BLUEPRINT.md."

author: "Roedy Rustam"

---

# Auto Documentation Updater (2026 — ADR Edition)

[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)

---

<a name="english"></a>

## English

### Description

Automatically maintains project documentation after every successful build or feature implementation. Updates `CHANGELOG.md`, `BLUEPRINT.md`, and introduces **Architecture Decision Records (ADRs)** — immutable records of key architectural decisions made throughout the project lifecycle.

### Trigger Conditions

- A feature, bug fix, or refactor has been successfully implemented and verified.

- The user asks to "update docs", "document this", or "save progress".

- After completing a phase in `zero-to-prod-orchestrator`.

- A significant architectural decision was made (DB choice, auth flow, API design).

### Files Maintained

| File | Purpose | Update Frequency |

|---|---|---|

| `CHANGELOG.md` | User-facing list of changes | Every PR / feature |

| `BLUEPRINT.md` | Technical architecture overview | Major structural changes |

| `PROGRESS.md` | Development roadmap and status | Each work session |

| `docs/adr/` | Architecture Decision Records | Each key decision |

### CHANGELOG.md Format (Keep-a-Changelog Standard)

```markdown

# Changelog

All notable changes to this project will be documented in this file.

Format based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).

## [Unreleased]

### Added

- New feature or capability

## [1.2.0] — 2026-07-29

### Added

- Super Admin dashboard on `admin.domain.com` with tenant management

- Polar.sh billing integration as alternative to Stripe

- `spa-orchestrator` skill for SPA architecture decisions

### Changed

- Upgraded React to 19.x with new Compiler (removes need for useMemo/useCallback)

- Migrated from `tailwind.config.js` to CSS-first `@theme` configuration (Tailwind v4)

### Fixed

- N+1 query issue in workspace members list endpoint

- Memory leak in WebSocket connection cleanup

### Security

- Upgraded Supabase client to Auth v3 with PKCE flow (replaces implicit flow)

- Service role key moved out of client-side code

## [1.1.0] — 2026-06-15

### Added

...

```

### BLUEPRINT.md Structure

```markdown

# [Project Name] — Technical Blueprint

## Architecture Overview

[High-level diagram or description]

## Tech Stack

| Layer | Technology | Version |

|---|---|---|

| Frontend | Next.js | 15.x |

| Backend | Hono | latest |

| Database | PostgreSQL + Drizzle | — |

| Auth | Supabase Auth | v3 |

## Entry Points

| URL | Purpose |

|---|---|

| `domain.com` | Marketing/Landing |

| `app.domain.com` | SaaS App |

| `admin.domain.com` | Super Admin |

## Database Schema (Summary)

[Key tables and relationships]

## API Endpoints (Summary)

[Key routes and their purposes]

## Environment Variables Required

[List of all required env vars]

```

### Architecture Decision Records (ADRs)

ADRs are **immutable records** of significant architectural decisions. Once created, they are never deleted — only superseded by a new ADR. This creates a historical audit trail of *why* the system is built the way it is.

#### ADR Template (`docs/adr/ADR-NNN-title.md`)

```markdown

# ADR-001: Use Supabase for Authentication and Database

**Status**: Accepted

**Date**: 2026-07-29

**Deciders**: [Team/Individual]

## Context

[What is the situation that motivated this decision? What forces are at play?]

We need a database + authentication solution for our SaaS MVP that can be

delivered quickly without managing infrastructure.

## Decision

We will use Supabase as our primary backend-as-a-service, providing:

- PostgreSQL database with Row Level Security (RLS)

- Auth v3 with PKCE flow (OAuth, magic links, MFA)

- Realtime subscriptions

- Storage for user-uploaded files

## Rationale

- Faster time-to-market than self-hosted Postgres + separate auth service

- Built-in RLS for multi-tenant isolation without custom middleware

- Open-source — can self-host later if needed

- Strong TypeScript SDK with auto-generated types

## Consequences

**Positive:**

- No auth infrastructure to manage

- RLS enforced at DB level — defense in depth

**Negative:**

- Vendor dependency — migration would require significant refactor

- RLS requires careful testing to avoid data leakage bugs

## Superseded By

[ADR-XXX: Migrated to self-hosted Supabase] (if applicable)

```

#### ADR Index (`docs/adr/README.md`)

```markdown

# Architecture Decision Records

| # | Title | Status | Date |

|---|---|---|---|

| [ADR-001](./ADR-001-supabase-auth.md) | Use Supabase for Auth + DB | ✅ Accepted | 2026-07-29 |

| [ADR-002](./ADR-002-polar-billing.md) | Use Polar.sh for billing | ✅ Accepted | 2026-07-29 |

| [ADR-003](./ADR-003-rls-isolation.md) | Shared Schema + RLS for multi-tenancy | ✅ Accepted | 2026-08-01 |

| [ADR-004](./ADR-004-ssr-vs-spa.md) | Next.js SSR for main app, SPA for admin | 🔄 Proposed | 2026-08-05 |

```

### Update Protocol

After every successful feature implementation:

1. **CHANGELOG.md**: Add entry under `[Unreleased]` with correct category (Added/Changed/Fixed/Security).

2. **BLUEPRINT.md**: Update only if schema, stack, or entry points changed.

3. **PROGRESS.md**: Mark completed tasks `[x]`, update next steps.

4. **ADR**: Create a new ADR if a significant architectural decision was made (DB choice, auth flow, billing provider, deployment strategy, isolation strategy).

---

<a name="bahasa-indonesia"></a>

## Bahasa Indonesia

### Deskripsi

Secara otomatis memelihara dokumentasi proyek setelah setiap build atau implementasi fitur yang berhasil. Memperbarui `CHANGELOG.md`, `BLUEPRINT.md`, dan memperkenalkan **Architecture Decision Records (ADR)** — catatan permanen dari keputusan arsitektur kunci yang dibuat sepanjang siklus hidup proyek.

### Kondisi Pemicu

- Sebuah fitur, perbaikan bug, atau refactor berhasil diimplementasikan dan diverifikasi.

- Pengguna meminta "perbarui docs", "dokumentasikan ini", atau "simpan progres".

- Setelah menyelesaikan fase dalam `zero-to-prod-orchestrator`.

- Keputusan arsitektur signifikan dibuat (pilihan DB, alur auth, desain API).

### File yang Dipelihara

| File | Tujuan | Frekuensi Pembaruan |

|---|---|---|

| `CHANGELOG.md` | Daftar perubahan untuk pengguna | Setiap PR / fitur |

| `BLUEPRINT.md` | Gambaran arsitektur teknis | Perubahan struktural besar |

| `PROGRESS.md` | Roadmap dan status pengembangan | Setiap sesi kerja |

| `docs/adr/` | Architecture Decision Records | Setiap keputusan kunci |

### Format CHANGELOG.md (Standar Keep-a-Changelog)

Gunakan kategori: `Added`, `Changed`, `Fixed`, `Removed`, `Security`. Simpan versi yang belum dirilis di bagian `[Unreleased]` dan turunkan ke versi bernama saat rilis.

### Struktur BLUEPRINT.md

Ringkasan arsitektur teknis termasuk: stack teknologi dengan versi, entry points (URL), skema database (ringkasan), endpoint API kunci, dan variabel lingkungan yang diperlukan.

### Architecture Decision Records (ADR)

ADR adalah **catatan permanen** dari keputusan arsitektur yang signifikan. Setelah dibuat, tidak pernah dihapus — hanya digantikan oleh ADR baru. Ini menciptakan jejak audit historis tentang *mengapa* sistem dibangun seperti yang ada.

Setiap ADR mencakup: Konteks (situasi yang memotivasi keputusan), Keputusan (apa yang diputuskan), Rasional (mengapa), Konsekuensi (positif dan negatif), dan Digantikan Oleh (jika berlaku).

Kelola ADR dengan indeks di `docs/adr/README.md` yang mencantumkan semua ADR dengan status (Diterima, Ditolak, Diusulkan, Usang).

### Protokol Pembaruan

Setelah setiap implementasi fitur yang berhasil:

1. **CHANGELOG.md**: Tambahkan entri di `[Unreleased]` dengan kategori yang benar.

2. **BLUEPRINT.md**: Perbarui hanya jika skema, stack, atau entry points berubah.

3. **PROGRESS.md**: Tandai tugas selesai `[x]`, perbarui langkah selanjutnya.

4. **ADR**: Buat ADR baru jika keputusan arsitektur signifikan dibuat.