0002 — Provisioning and onboarding UI gaps (admin-console / learner-web)
Status: candidate Opened: 2026-07-10 · Area: admin-console, learner-web (identity & membership surfaces) Reopen trigger: the first deployment where an operator must provision a real Organization/cohort without shell access to the database, or the first cohort that must be onboarded by invitation rather than self-serve joining.
Evidence
Section titled “Evidence”Found while writing the v1 end-user docs (ADR-0051): the “no vaporware” rule required grounding every guide in shipped UI, and these in-scope flows have no UI surface (grep- and route-level confirmed, 2026-07-10):
- Organization creation / first-run provisioning — admin-console only selects among existing
Organizations (
ScopeSummaryCard) and edits an Organization’s image/issuer profile. Nothing creates one. - Claim Token issuance or redemption — the domain concept exists (CONTEXT.md; pre-provisioned Persons rebound at redemption) but neither admin-console (issuance) nor learner-web (redemption) exposes it. Zero hits for claim-token surfaces in either app.
- SIS / OneRoster import trigger — admin-console shows the consequences of imports (identity Correlation Review queues, resource-catalog curation) but has no way to start or monitor an import run.
- Learner enrollment / direct Membership management — the only membership-granting admin action
is the staff portal invite (teacher / assistant / observer / mentor / org-admin / platform-admin;
no learner role). Learner-web onboarding is exclusively the self-serve Join offering button
on the Offerings list (
joinOfferinginfeatures/sync/lib/sync.tsx) — open joining, no invitation or roster-driven path. - Related loose end:
root.nav.offeringsi18n key exists in admin-console with no route behind it; Offering creation lives only in teacher-portal.
Disposition
Section titled “Disposition”The v1 docs document the real paths only (staff invites; self-serve joining) and state the boundaries explicitly (“Portal invites provision staff and administrators, not learners”). Under the standards-driven-discovery rule these gaps are candidate features, not doc stubs — each needs its own product decision (e.g. is open self-serve joining the intended learner onboarding for v1, or a prototype convenience?). When any of these lands, its guide belongs in the matching docs area, and the corresponding “gap” wording in the affected guides should be revisited.