Aori — Roadmap Implementasi dan Blueprint Eksekusi

Status: hidup dan wajib diperbarui pada setiap perubahan domain. Peta dokumen: 01.index. Source of truth arsitektur: 03.overview. Uji alur bisnis/invariant: 04.study. Aturan kerja agent/contributor: AGENTS.md pada root repository.

Dokumen ini bukan daftar fitur biasa. Ini adalah urutan implementasi Aori sebagai SaaS multi-tenant dan multi-database. Sebuah item hanya boleh dicentang setelah kontrak API, authorization, entitlement bila relevan, validasi, UI, error state, invalidation, test, dan dokumentasi selesai sesuai boundary-nya.

1. Cara Membaca dan Memperbarui

Setiap perubahan wajib memperbarui item terkait dengan tanggal, ringkasan hasil, validasi yang dijalankan, dan kendala. Jangan mencentang berdasarkan adanya model Prisma saja. Jangan mencentang UI bila API belum tenant-scoped dan terotorisasi.

Snapshot implementasi — 2026-10-22

• [x] Identity/auth dasar, User profile/personalization, Organization, Member/RBAC, Organization profile, address/link/FAQ, Workspace dasar, Team, Position, dan Employee lifecycle dasar tersedia pada Runner/API/container.
• [x] Billing schema/client dan katalog Plan publik tersedia; evaluator internal entitlement feature tersedia.
• [~] Project dapat dibuat dan status diubah; belum lifecycle/detail lengkap.
• [~] Collaboration API telah memiliki draft + owner party, party invite/accept, approval decision, activation, owner-workspace link, dan external participant. Container baru menyediakan draft/list/party acceptance; UI operasional detail, document lifecycle, quota metering, dan access enforcement lanjutan belum selesai.
• [ ] HR lanjutan (contract, shift, attendance, compensation, payroll), Catalog, Commerce, Inventory, outbox/inbox, observability/audit/retention production belum selesai.

2. Blueprint Kepemilikan dan Dependency Database

Semua komunikasi lintas domain mengikuti pola:

command di owner DB
  → local transaction + outbox event ber-idempotency
  → publisher
  → inbox consumer per domain
  → projection/read model atau compensation/reconciliation

Tidak ada transaction Prisma, cascade, foreign key, atau join MongoDB lintas lima database. ID lintas domain adalah reference opaque/scalar yang divalidasi oleh service pemiliknya.

3. Gate Universal Sebelum Fitur Dianggap Selesai

• Kontrak request/response/error code ditulis dan divalidasi di API secara mandiri tanpa Zod; unknown field, nested object, pagination, enum, format, dan size limit ditolak.
• Actor dari session/trusted proxy; userId, role, ownership, tenant, price, total, status, serta permission dari client tidak pernah dipercaya.
• Tenant scope dimulai dari resource owner dan diverifikasi kembali untuk relation.
• Authorization dan entitlement adalah dua pemeriksaan terpisah; quota dihitung oleh domain pemilik resource secara atomik.
• Mutation yang dapat retry memiliki idempotency key atau invariant unik yang aman; race condition diuji.
• Response hanya berisi projection aman; BigInt serialisasi aman sebagai string.
• Container mem-parse seluruh network payload melalui Zod v4 di schema/.
• UI memiliki loading, empty, forbidden, error, success, keyboard/focus, i18n, invalidation/refetch yang eksplisit; mutasi sensitif tidak optimistic.
• Test normal, unauthorized, forbidden, tenant mismatch, duplicate/retry, expiry, stale state, dan retention bila relevan telah dijalankan.

4. Tahap 0 — Engineering Governance dan Platform Baseline

Dependency: tidak ada. Database: seluruhnya. Tujuan: menjadikan perubahan berikutnya aman, terukur, dan dapat ditelusuri.

• [~] Monorepo, internal packages, container host, API proxy, i18n, form primitive, HTTP status, dan Prisma clients tersedia.
  • Catatan: import ESM packages/auth/src/validation.ts telah dinormalisasi untuk NodeNext; typecheck API perlu dijalankan ulang pada akhir tahap untuk memastikan tidak ada blocker toolchain lain.
  • Catatan: lint container terblokir resolusi lama eslint-config-next/core-web-vitals.
• [~] Initial-load Container dipisahkan dari data non-kritis: server session/cookie menjadi first paint; daftar multi-session memakai snapshot session aktif dan hanya melakukan refresh authoritative lewat aksi eksplisit. Personalization kini dipisahkan dari context-session; policy sync lintas-device sengaja belum diaktifkan kembali. Sisa: ukur Web Vitals dan audit provider/layout lain untuk waterfall atau refresh loop.
• [ ] Perbaiki blocker toolchain tanpa mengubah semantics aplikasi; CI menjalankan lint/typecheck/test untuk semua workspace.
• [ ] Establish API contract tests, integration test database terisolasi, seed aman, fixture multi-tenant, dan test idempotency.
• [ ] Structured log, request/correlation ID, metrics, trace, health/readiness, error taxonomy, alert policy, dan dashboard operasi.
• [ ] Security baseline: secret rotation, CSP, rate limit, abuse detection, dependency audit, backup/restore drill, vulnerability response, dan incident runbook.
• [ ] ADR (architecture decision record) untuk tenancy, eventing, document/media, payment provider, data retention, dan external collaboration.

5. Tahap 1 — Identity, Session, Profile, dan Personal Privacy

Owner: Runner. Actor: User global. Tidak membuat Organization otomatis.

• [x] Signup/signin/signout, multi-session, credential navigation, password flows, User, Account, Session, Verification, UserProfile, dan personalization dasar.
• [x] Onboarding awal hanya profile User; user tanpa Organization tetap valid.
• [~] Personalization sync lintas device dan cookie snapshot diperbaiki.
  • Sisa: test multi-device/focus/reconnect/locale transition secara otomatis.
• [ ] Passkey lifecycle: enrol, challenge, recovery, revoke, device label, audit.
• [ ] TwoFactor lifecycle: policy enforcement, backup/recovery code, revoke, audit.
• [ ] OAuth account linking/unlinking dan collision account policy.
• [ ] Privacy/export/delete request: legal hold, notification, delayed purge, export, and redaction projection lintas domain.
• [ ] JWK/key rotation dan token/session compromise response.

Exit gate: user dapat memakai aplikasi tanpa tenant; semua auth mutation aman terhadap open redirect, CSRF/session fixation, retry, enumeration, dan rate-limit abuse.

6. Tahap 2 — Organization, Membership, RBAC, dan Workspace Dasar

Owner: Runner. Tenant root: Organization. Dependency: Tahap 1.

• [x] Organization/profile creation, owner Member, active organization selection, member invitation/accept/revoke, Permission/PermissionRole, RoleHistory dasar.
• [x] Workspace CRUD dasar; Workspace tidak dapat ada tanpa Organization.
• [~] Member ↔ WorkspaceMember assignment tersedia lewat management Member.
  • Sisa: dedicated workspace member lifecycle, suspend/revoke reasons, audit list, pagination/filter/search, dan permission granularity.
• [ ] Permission catalog lifecycle: migration/versioning, role template, effective permission inspection, break-glass policy, review/certification, audit export.
• [ ] Organization archive/export/retention policy; child organization semantics bila dipertahankan harus tidak mengaburkan tenant root.
• [ ] Organization category vocabulary/template system: hanya presentation/module order, tidak pernah memberi role, feature access, entitlement, atau URL palsu.
• [ ] Workspace operational resource model dan per-request access middleware yang memeriksa owner organization + membership/participant state.

Study verification: 04.study.md STEP 2–6, 9, 14, 15.

7. Tahap 3 — Internal Organization Structure dan HR Foundation

Owner: Runner. Dependency: Member/RBAC. Data sensitivity: tinggi.

• [x] Team (organizationId wajib, workspaceId opsional), TeamMember tenant-safe, Position hierarchy, Employee conversion from active Member, EmployeePositionHistory, basic lifecycle status, dan UI dasar.
• [~] Team lifecycle.
  • Archive UI telah memakai endpoint archive (bukan delete), sehingga sejarah tetap attributable. Edit Team UI dan assignment revoke telah terintegrasi di host container dengan validasi Zod v4, server action PATCH/DELETE yang tenant-safe, dan refresh otoritatif.
  • Sisa: Team policy/leadership model, audit/history viewer, dan pagination untuk tim/member besar.
• [~] Position lifecycle.
  • Update/deactivate UI telah menggunakan validasi Zod dan API hierarchy-cycle check.
  • Sisa: historical assignment impact, role/grade policy, dan detail/audit viewer.
• [~] Employee lifecycle.
  • Sisa: employee detail boundary, change position UI + history viewer, sensitive field encryption/redaction/audit, rehire, termination reason, document references, bulk import.
• [ ] EmployeeContract: contract type, effective dates, renewal, expiry, signed document opaque reference, approval, archive/legal retention.
• [ ] Shift and EmployeeShift: timezone, schedule, recurrence, conflict detection, assignment, effective date, absence/holiday policy.
• [ ] EmployeeAttendance: clock-in/out, geolocation/device/privacy policy, correction, approval, anti-fraud, immutable audit, shift integration.
• [ ] EmployeeCompensationComponent: money minor-unit BigInt, effective date, immutable version/snapshot, approval, tax/BPJS policy, no client calculation.
• [ ] BankAccount: encrypted/redacted fields, verification, access audit, change approval.
• [ ] Payroll/PayrollItem: period lock, server calculation, attendance/contract snapshot, approval/payment lifecycle, immutable finalized ledger, correction by reversal, export, archive/purge/legal hold.

Study verification: 04.study.md STEP 5, 7–12, 14.

8. Tahap 4 — Project, Collaboration, dan External Workspace Access

Owner: Runner + Billing entitlement. Dependency: Tahap 2, Team/Member, Billing entitlement. Security rule: external person never becomes Member of host tenant.

4A. Project

• [x] Project create/list/status update with tenant permission.
• [~] Full basic edit (name, code, description, timeline, status) is available through the same server-validated Project contract as creation.
  • Selesai pada tahap ini: tenant-scoped code uniqueness validation, lifecycle transition policy (draft → active/cancelled, active ↔ on_hold, terminal completion/cancellation → archived), serta compare-and-set update untuk mencegah stale status transition menimpa perubahan terbaru.
  • Sisa: deliverable/timeline/budget model, Project–Workspace association, Project audit/read model.

4B. Collaboration aggregate

• [x] Draft creates accepted owner party atomically.
• [x] Party invitation with organization/team/representative, scope subset, validity boundary, accepted party flow, approval requirement/decision, activation gate, owner-workspace link, and external WorkspaceParticipant API.
• [x] collaboration.enabled feature entitlement is checked for owner-side mutations.
• [~] Container supports draft/list, acceptance by invited tenant, serta owner-side proposal dan reversible suspend/resume dengan authoritative refresh. Owner dapat menambah approval requirement untuk party yang sudah ada serta meminta aktivasi; API tetap memutuskan kelayakannya.
  • Sisa: permission-aware owner console for party invite, approval decision, workspace link, participant assignment/revoke, status/history detail, dan confirmation+reason UX untuk termination/archive.
• [ ] CollaborationDocument: document/media service contract, opaque document reference, issuer validation, verification metadata, NDA/agreement/minutes/attachment, expiry, access policy, immutable audit, retention/legal hold.
• [~] Lifecycle transitions owner-side: propose, suspend/resume, terminate, archive, revoke non-owner party (termasuk revoke seluruh external participant terkait), dan revoke external participant sudah tersedia pada API.
  • Sisa: automatic expiry job, party suspension/resume, reason/note/audit event per mutation, notification, UI lifecycle operasional, dan policy archive/retention.
• [ ] requiredByTeamRole requires an explicit Team role model/policy before it is exposed; do not pretend TeamMember has a role it does not store.
• [ ] Entitlement quotas: external party max, workspace max, external participant max; owner domain atomically counts usage then emits idempotent UsageRecord to Billing.
• [ ] Access middleware on every workspace resource checks Collaboration active, party accepted, approval complete, scope subset, participant active, validity windows, and immediate revocation/expiry.
• [ ] Cross-organization organization discovery/invitation policy. Do not expose a global tenant directory without privacy, anti-enumeration, and consent design.

Study verification: 04.study.md STEP 17–18; especially 17 Agustus multi-party scenario.

9. Tahap 5 — Billing, Subscription, Entitlement, dan Retention

Owner: Billing. Dependency: Runner organization exists. Boundary: Billing grants capability/quota, never actor permission.

• [x] Billing schema/client, Plan version model, public active-plan catalogue, and internal effective feature entitlement lookup.
• [~] Container pricing board reads public plan data.
  • Sisa: UI must never hardcode source-of-truth price/features.
• [ ] BillingAccount creation and tenant ownership verification against Runner.
• [ ] Subscription checkout command: provider abstraction, idempotency key, secure redirect, provider reference secrecy, webhook signature/replay validation.
• [ ] Subscription state machine: trial/active/grace/restricted/ended/archived; billing projection to effective Entitlement with deterministic precedence.
• [ ] Entitlement evaluator including quota values and atomic usage decision contract.
• [ ] UsageRecord inbox/outbox/metering: producer idempotency key, dedupe, retry, reconciliation, late event policy; no synchronous Billing write in operational request.
• [ ] BillingInvoice/BillingPayment lifecycle; explicitly distinct from Commerce invoice/payment.
• [ ] Restricted read-only enforcement, account archive, retention/legal hold, notification, export window, purge job and irreversible deletion safeguards.

Study verification: 04.study.md STEP 16 and retention section.

10. Tahap 6 — Catalog Domain

Owner: Catalog. Dependency: Organization scalar tenant key + Billing entitlement + Runner authorization composition. No Runner FK.

• [~] Product/category functionality operates against Catalog database through tenant/RBAC composition. Product create/update/archive now appends an idempotent Catalog outbox event in the same local transaction; archive replaces physical delete. Price lists and immutable price versions now have tenant-scoped API contracts; price mutations reject floating-point money and overlapping active target/tier validity windows, then append catalog.price.changed locally.
  • Price entry host sekarang dimulai dari Product → valid PriceList → immutable Price version; list validity diperiksa lagi API sebelum write dan history dibatasi ke Product terkait. Perintah create Price kini membawa UUID idempotency key yang tersimpan bersama hash payload privat. Retry dengan payload sama mengembalikan versi yang telah dibuat; reuse key untuk payload atau PriceList lain ditolak tanpa membuat versi baru.
  • Sisa: outbox publisher lease/retry/dead-letter, Inventory/Commerce inbox consumers dan projections, date/tier price editor lengkap, dan migration of remaining legacy product naming.
• [ ] Catalog schema finalization: product/service, category, variant, attribute, media opaque references, price list, tax class, promotion eligibility, status/version.
  • ProductVariant API lifecycle is available (tenant resolution through parent Product, manual bounded attributes validation, archive-not-delete, and parent projection event). Host juga telah memiliki action archive tenant-scoped dengan refresh otoritatif. Media, identifiers, categories, service definitions, tax, promotion, and read-model contracts are still not exposed.
• [ ] Catalog APIs: tenant scope, product permission, entitlement, pagination/filter/search, immutable price versioning and BigInt money.
  • Category legacy handlers now reject unknown/invalid input, resolve parent categories in the same tenant, hide archived rows, and archive instead of physically deleting. Search, pagination, entitlement, media and complete category/product composition remain open.
• [ ] Event contracts: catalog.product.published, catalog.price.changed, catalog.product.archived; idempotent consumers and projection versioning.
  • Versi awal @repo/events sekarang mendefinisikan envelope JSON-safe berversi dan payload Catalog Product/Price. Outbox Catalog menyimpan envelope tersebut dengan eventId yang sama; correlation/causation masih null sampai request context dan publisher/inbox lintas domain tersedia.
• [ ] Container/catalog MFE routes with safe Zod schemas, server access gating, list/detail, form, error/empty/loading and cache invalidation.
  • Container sekarang memiliki host route /org/[slug]/catalog untuk Product identity/content: server access gate, Zod v4 response/form validation, create/edit pessimistic refresh, loading transition, empty/error access state, dan shortcut capability kategori yang hanya muncul setelah route benar-benar ada. Variant nested route tersedia untuk identity SKU turunan Product yang tervalidasi dan dapat diarsipkan. PriceList metadata juga dapat dibuat/dibaca/diarsipkan dari host; entry harga per produk memakai idempotency key, sedangkan pagination, granular navigation permission/entitlement, date/tier editor, dan MFE remote boundary masih terbuka.

11. Tahap 7 — Inventory Domain

Owner: Inventory. Dependency: Catalog projection; entitlement; warehouse permission. Rule: stock truth is immutable movement ledger, not client quantity.

• [ ] Warehouse, location/bin, stock item/balance projection, reservation, lot/batch, serial policy, stock movement/adjustment/transfer/count schemas.
• [ ] Reservation lifecycle with idempotency and expiry; authoritative availability endpoint.
• [ ] Inventory commands validate tenant, authorization, product projection, quantity bounds, concurrency/optimistic version or ledger invariant; no price from client.
• [ ] Event contracts to/from Commerce: reserve/confirm/release/fulfill/return; compensation and reconciliation dashboard.
• [ ] Warehouse/inventory MFE with ledger-first UI, scan accessibility, offline policy only if reconciliation is designed; no localStorage stock source of truth.

Study verification: 04.study.md STEP 13A–13B.

12. Tahap 8 — Commerce Domain

Owner: Commerce. Dependency: Catalog projection, Inventory reservation, Billing entitlement, Runner actor composition. Commerce invoice ≠ BillingInvoice.

• [ ] Customer/contact/address snapshot model; customer identity/privacy policy.
• [ ] Cart/quote/order state machine, server-authoritative price/tax/discount snapshot, idempotent checkout/order command, cancellation/return/refund policy.
• [ ] Customer Invoice, Commerce payment, shipment/fulfilment lifecycle; provider webhooks validated, replay safe, monetary amounts BigInt minor units.
• [ ] Outbox/inbox flows with Inventory and Catalog projections; reserve → confirm/release, shipment events, failed compensation and reconciliation.
• [ ] Commerce MFE routes with permission/entitlement gate, authoritative mutation result, no optimistic stock/payment/order finality.

13. Tahap 9 — Cross-Domain Read Models, Eventing, and Reconciliation

Dependency: each owner domain command is stable first.

• [ ] Shared event envelope: event ID, aggregate/version, organizationId, occurredAt, correlation/causation ID, schema version, idempotency key, PII classification.
• [ ] Per-database outbox, publisher lease/retry/dead-letter and inbox dedupe tables.
• [ ] Consumer ordering/duplicate/out-of-order strategy; poison-event tooling and replay.
• [ ] Projection/composition service contracts for dashboard/search/report; no hidden cross-DB join from UI request.
• [ ] Reconciliation jobs for subscription usage, catalog/commerce price mismatch, commerce/inventory reservation, payroll/payment and document references.
• [ ] Data migration/versioning and backfill protocol with rollback/repair plan.

14. Tahap 10 — Audit, Compliance, Data Lifecycle, and Operations

• [ ] Immutable audit event model/service for access, RBAC, HR, collaboration, money, document, retention, and privileged support action.
• [ ] Actor impersonation/support policy with explicit consent, audit, expiry and no secret exposure.
• [ ] Data classification, PII redaction, encryption-at-rest/field encryption, key access, download watermarking where required.
• [ ] Retention policy engine: active → archived → legal-hold check → warning/export → scheduled purge; every job idempotent and auditable.
• [ ] Organization backup/export, restore boundaries, disaster recovery RPO/RTO test.
• [ ] Operational dashboards for auth abuse, queue lag, event failures, entitlement denial, collaboration expiry, payroll lock, stock reconciliation, and data purge.

15. Tahap 11 — Product Experience, MFE, and Scale

• [~] Mobile auth foundation berada pada repository saudara C:\Data\AORI-Projects\aori-mobile: Expo Router protected groups memisahkan route publik dan operasional; credential email/password memperoleh bearer session Better Auth melalui API, token hanya disimpan di Expo SecureStore, dan cold start selalu memvalidasinya kembali lewat get-session.
  • OAuth provider (Google, GitHub, Apple, Microsoft bila dikonfigurasi) kini memakai mobile grant bridge: API membuat attempt berumur 10 menit dengan exchange-secret yang hanya ada di memori aplikasi, Better Auth menyelesaikan provider di browser, dan callback deep-link membawa grant opaque sekali pakai—bukan session/bearer token. API mengenkripsi token cookie sementara menggunakan BETTER_AUTH_SECRET, menukarnya sekali melalui HTTPS, lalu menghapus verification record secara atomik. AORI_MOBILE_AUTH_CALLBACK_URL pada API dan EXPO_PUBLIC_AORI_AUTH_CALLBACK_URL pada mobile harus identik (aori://auth/callback); nilai default hanya untuk local development.
  • Batas saat ini: MFA, passkey, recovery, account linking/unlinking, device/session management, API client domain, Zod response schema mobile, i18n, dan universal-link/app-link hardening belum tersedia. EXPO_PUBLIC_AORI_API_URL harus diarahkan ke HTTPS/reachable API (bukan localhost pada perangkat fisik). Bridge tidak boleh dianggap pengganti universal link pada production.
  • Lokasi implementasi aktif: C:/Data/AORI-Projects/aori-mobile. SDK 58 memerlukan root route konkret di src/app/index.tsx; route tersebut dilindungi bersama (app), sementara Stack.Protected menjadi satu-satunya mekanisme redirect menuju auth agar perubahan sesi tidak menciptakan loop navigasi. Respons user Better Auth diparse menjadi projection aman sebelum dipakai state sesi.
  • [~] Mobile profile edit memakai PATCH /api/users/me dengan bearer session, validasi input lokal minimal, state submitting yang menonaktifkan field, dan update state hanya dari respons API tervalidasi. Avatar/media, verifikasi telepon/email, recovery, dan pengelolaan session/device tetap belum tersedia.
  • [~] Mobile security screen tidak lagi memakai switch dua faktor atau daftar perangkat palsu. Ia hanya menampilkan status two-factor dari projection sesi; password, re-authentication, recovery, dan session/device management menunggu lifecycle native yang lengkap.
  • [~] Mobile notification screen tidak lagi menyimpan toggle lokal semu. Delivery preference menunggu push-token registration, izin perangkat, preference API, dan audit delivery yang konsisten.
  • [~] Mobile password change tersedia melalui POST /api/users/me/password: current password, password baru, dan pilihan revoke sesi lain dikirim melalui bearer session; API tetap memeriksa freshness/policy/password lama dan UI tidak melakukan optimistic update. Device-session inventory dan MFA management tetap belum tersedia.
  • [~] Mobile Organization context dapat membaca profil tenant yang member-safe melalui GET /api/organization/:organizationId, hanya atas aksi eksplisit, dengan parse runtime dan race protection. Endpoint Workspace masih owner-only sehingga tidak dipakai sebagai daftar Workspace universal untuk Member.
  • [~] GET /api/users/me/readiness menyediakan UserProfileReadiness v1 yang identity-only; Dashboard mobile merender progress profil dari respons tervalidasi, lazy pada focus dengan throttle dan stale-response guard. OrganizationReadiness dan MemberWorkReadiness belum dibuat karena membutuhkan checklist permission/entitlement dan lifecycle membership yang tidak boleh disatukan.
• [~] Mobile Organization context memuat projection aman dari GET /api/users/me/organizations hanya atas aksi eksplisit pengguna, mem-parse respons network sebelum dipakai, dan memilih konteks hanya di memori. Provider di-remount per user.id agar tenant akun sebelumnya tidak pernah tampak setelah sign-out/sign-in. Route/tab yang sebelumnya bernama Workspace telah dimigrasikan menjadi Organization karena layar ini bukan daftar Workspace.
  • Layar Organization mobile kini melakukan initial load saat route mendapat focus, hanya ketika state masih idle; refresh manual tetap tersedia dan selection tetap memory-only. Request tidak dipicu dari render dan tidak mengubah boundary authorization API.
  • [~] Dashboard, aktivitas, Catalog, dan Commerce mobile tidak lagi mengonsumsi data contoh perangkat. Saat kontrak read model tenant-scoped belum ada, layar menampilkan empty/unavailable state yang jelas. Daftar Workspace juga sengaja belum diintegrasikan: endpoint yang ada saat ini owner-only, sehingga tidak aman dipakai sebagai daftar universal bagi Member.
  • [~] Ikon navigasi dan affordance mobile memakai expo-symbols atau image asset yang valid; ikon berbasis karakter string dan data mock legacy src/data/workspace.ts telah dihapus. Penggantian icon native tab dapat tetap memakai asset raster multi-ukuran yang sudah tersedia.
• [ ] Route map per capability/MFE with host ownership, remote boundary, contract version, fallback/error isolation, and progressive loading.
• [ ] Mobile Remote Config/SDUI/OTA foundation: policy telah dikunci pada root dan mobile AGENTS.md (presentational-only config, validated native registry/action allowlist, built-in fallback, tenant-safe delivery, dan OTA runtime boundary). Implementasi service/config API, cache, registry, Dashboard pilot, test matrix, dan EAS Update activation belum dimulai.
• [ ] Navigation derived from permission + entitlement + capability availability; category changes labels/template only.
• [ ] Responsive/mobile, keyboard, screen-reader, locale/RTL, timezone/currency formatting, large-list virtualisation/pagination, and performance budgets.
• [ ] Notification center, email/push preference, digest, delivery audit, and external invite notification with privacy-safe content.
• [ ] Search/read model, reporting/export, analytics consent, usage reporting, and data minimization.
• [ ] Multi-region/scale plan: tenant routing, cache key tenancy, rate limits, queue partitioning, backpressure, SLOs, capacity/load/chaos tests.

16. Route and Contract Delivery Checklist

Untuk setiap route baru, tambahkan baris status di fase domain terkait dan pastikan:

1. Owner DB, tenant scalar/relation, actor, permission, entitlement, lifecycle, and data classification dicatat.
2. API validates parameter/query/body manually; unknown keys rejected; response projection safe; idempotency stated.
3. Event/outbox/projection impact dicatat bila menyentuh database lain.
4. Container Zod schema, server gate, mutation invalidation, i18n, accessibility, and states selesai.
5. Test matrix dan 04.study.md scenario mapping diperbarui.
6. Checklist dalam roadmap diperbarui bersama catatan positif/kendala/risiko.

17. Change Log Roadmap

| 2026-10-28 | Sheets modal performance/accessibility | Core Sheets mengurangi listener Escape saat tertutup, memindahkan multiple-open render scheduling ke provider tunggal, mencegah setiap panel mengunci scrollbar, dan menambahkan focus trap pada modal content. Scrollbar lock kini ref-counted agar beberapa modal tidak saling menghapus style body; browser verification dan a11y test otomatis masih terbuka. |

18. Definition of Done Produk Besar

Aori tidak dianggap selesai hanya karena halaman atau model sudah ada. Target akhir tercapai apabila setiap domain owner dapat bekerja independen dengan kontrak event/versioning yang teruji; tenant tidak dapat bocor; entitlement dan permission tidak saling menggantikan; money/stock/payroll/legal record authoritative serta auditable; recovery/retention/operation teruji; dan pengalaman User, Member, Employee, owner, serta collaborator eksternal jelas tanpa memalsukan relasi Organization–Workspace–Project–Collaboration.