Skip to content
XPrivate Education — Knowledge Base

Iter Boundaries

Iteration Boundaries (Iter 1 = Admin-MVP)

Section titled “Iteration Boundaries (Iter 1 = Admin-MVP)”

Scope guard. Iter 1 is a pure admin backoffice. Customer-facing self-service is iter 2+. When unsure: make the schema ready, do NOT build the feature. Full scope: plans/scope/001-mvp.md.

Iter 1 — ACTIVE (build it)

Section titled “Iter 1 — ACTIVE (build it)”
  • Admin login: Google OAuth, domain-restricted @xprivate.education.
  • Custom RBAC (runtime-editable permission matrix).
  • Master data CRUD, scheduling, billing/settlement, business audit, HR, finance — all backoffice.
  • Tutor/siswa actions (start sesi, attendance, materi, foto report) = admin proxy: admin enters on their behalf. Audit actor = admin, subject = tutor/sesi.

Iter 2+ — DEFERRED (do NOT build UI/flows now)

Section titled “Iter 2+ — DEFERRED (do NOT build UI/flows now)”
  • Customer self-service: siswa/tutor/parent signup, self-mark attendance, dispute UI.
  • Payment gateway, auto-notifications, Zoom integration, mobile push.
  • Tutor/siswa/parent portal logins.

DB-ready, code-flip pattern

Section titled “DB-ready, code-flip pattern”

These are schema-present in iter 1, activated by a code change in iter 2+ with no migration. Build the schema; leave the feature gated:

  • UserType TUTOR / SISWA / PARENT (only ADMIN active iter 1).
  • Multi-IdP / multi-identity, 2FA (two_factor), magic link, password reset.
  • Full AccountState machine (iter 1 uses only ACTIVE — see domain-state-machines.md).
  • login_audit_events.

Rule of thumb: a feature flagged “iter 2+” in ARCHITECTURE or scope means the table may exist, but no UI, route, or service flow should activate it. Do not delete or stub away the DB-ready schema — it is intentional.