docs: record sponsor approval of NewUser normalization decisions

Mark brief §5 decisions resolved (all recommendations accepted 2026-06-20): NewUser canonical for direct provision, SuperRegister deleted + redirected, Registration label tidied.
This commit is contained in:
daniel-c-harvey
2026-06-20 00:34:44 -04:00
parent 1dd1646cce
commit c4e22c706c
@@ -4,7 +4,7 @@
`C:\Development\AuthBlocks`. You do not need, and should not assume, any knowledge of the products that
consume AuthBlocks. Everything you need is in this brief or in that one repo.
**Status:** scoped request, not yet started. Author: product-designer (for a downstream consumer team).
**Status:** scoped request, **decisions approved 2026-06-20** — ready for implementation. Author: product-designer (for a downstream consumer team).
Date: 2026-06-20.
---
@@ -205,22 +205,21 @@ form.
---
## 5. Decisions for the sponsor (Daniel) — resolve before/while implementing
## 5. Decisions for the sponsor (Daniel) — resolved 2026-06-20
1. **Which page is canonical for direct provision?** Recommendation: **New User** (`/useradmin/users/new`),
absorbing SuperRegister (§3.1). Confirm, or choose Alternative B (SuperRegister stays, NewUser redirects).
2. **What happens to SuperRegister?** Recommendation: **delete + redirect `/account/superregister` →
`/useradmin/users/new`.** Alternatives: keep it as a permanent alias (more surface to maintain), or hard-
delete with no redirect (risks a 404 until the consumer updates its nav — see §7). Confirm.
3. **Route naming.** Recommendation: keep `/useradmin/users/new` as the canonical direct-provision route (it
matches the UserAdmin IA). Confirm there's no desire to keep an `/account/*` route for it.
4. **Copy/wording on NewUser.** Header ("Activate New User" vs. "New User — Direct Provision"), button
("Create Account" vs. "Provision User"), and body text. Recommendation in §3.1.2 — confirm exact strings,
or leave to implementer discretion within the intent.
5. **Tidy the Registration label** ("Provision New User" → "Invite New User"/"New Registration")? Recommended
for coherence (§3.1.4) but strictly optional and behavior-neutral. In or out?
6. **Future chooser page (Alternative D)** — explicitly defer, or capture as a follow-up? Recommendation:
defer; note as a possible later enhancement.
1. **Which page is canonical for direct provision?** **DECISION (2026-06-20): New User** (`/useradmin/users/new`)
is the canonical direct-provision page, absorbing SuperRegister (§3.1). ✅ approved.
2. **What happens to SuperRegister?** **DECISION (2026-06-20): delete + redirect** `/account/superregister` →
`/useradmin/users/new`. ✅ approved.
3. **Route naming.** **DECISION (2026-06-20):** keep `/useradmin/users/new` as the canonical direct-provision
route. No `/account/*` route retained. ✅ approved.
4. **Copy/wording on NewUser.** **DECISION (2026-06-20):** go with the recommended strings in §3.1.2 — header
"New User — Direct Provision" or "Activate New User"; button "Create Account"; accurate direct-provision body
copy. Implementer discretion within that intent. ✅ approved.
5. **Tidy the Registration label** ("Provision New User" → "Invite New User"/"New Registration")?
**DECISION (2026-06-20):** yes, in scope. ✅ approved.
6. **Future chooser page (Alternative D)** — **DECISION (2026-06-20):** deferred; captured as a possible later
enhancement. ✅ approved (defer).
---