# P3-admin-surface — findings | | | | --- | --- | | Reviewer | Zayed | | Reviewed | — | | Status | draft | | Supersedes | — | | Superseded by | — | **This prototype is a draft and its outcome column is empty on purpose.** Every decision below offers two defensible answers, both actually built and both switchable from the bar under the prototype header. The choice follows the reader from screen to screen and is written into the address. ## Outcome per decision | Id | Decision | Options built | Outcome | Evidence | Writes back to | | --- | --- | --- | --- | --- | --- | | **D3** | **The review pattern** — a queue, a detail, and a decision that requires a reason when it refuses. **P4's squad exceptions and P6's company verification reuse whichever answer this is, verbatim.** | a) queue and detail side by side, the decision taken in place — `review=split` b) the queue opens a detail **route** — `review=route` | | `screenshots/claims--default--ar--split.png`, `screenshots/claims--default--ar--route.png`, `screenshots/claim--default--ar.png`, `screenshots/clubs--default--ar--split.png`, `screenshots/clubs--default--ar--route.png`, `screenshots/claims--default--ar--mobile.png` | (c) a convention in the web repository, and (a) the claims and club-approval epics | | D1 | Administration has five entries in Stage 2 and will have more. Do they stay a **group in the rail**, or does administration become **an area with a tab strip**, as the club already is? | a) a group in the rail — `adminnav=groups` b) an area with a tab strip — `adminnav=area` | | `screenshots/admin--default--ar--groups.png`, `screenshots/admin--default--ar--area.png`, `screenshots/claims--default--ar--area.png` | (c) a convention | | D2 | Is a reference-data catalogue a **table with inline actions**, or a **list beside a detail**? | a) a table — `list=table` b) a list and a detail — `list=split` | | `screenshots/admin--default--ar--table.png`, `screenshots/admin--default--ar--split.png`, `screenshots/admin--default--en--table.png` | (a) the reference-data epic | | D4 | Naming a write's scope in the confirmation is settled. Is it **enough** for a destructive write, or must the name be typed back? And should a destructive write with **live dependents** be refused rather than confirmed? | a) the scope named — `confirm=named` b) named, and the name typed — `confirm=typed` | | `screenshots/admin--default--ar--confirm-named.png`, `screenshots/admin--default--ar--confirm-typed.png`, `screenshots/item--error--ar.png` | (c) a rule for the code repository | ### Secondary questions the same screens answer | Question | Where it is visible | Writes back to | | --- | --- | --- | | A refusal reason is free text and the person refused reads it **verbatim**. Is that right, or should a refusal pick from a list of reasons so the copy can be translated and the data counted? | `screenshots/claim--partial--ar.png`, `screenshots/claims--default--ar--split.png` | (a) the claims epic | | A decided claim **stays readable** with its decision, its reason, its reviewer and its date. Does the same hold for a refused club, given a refused club may re-register? | `screenshots/claim--partial--ar.png` | (b) a note on the club-registration epic | | An empty catalogue breaks a sign-up form **silently** — a required control with no options. Should the registry refuse to serve a group whose catalogue is empty, or should the form say so? | `screenshots/admin--empty--ar.png`, `screenshots/registry--partial--ar.png` | (a) the reference-data epic | | The registry read page shows an **option count** per catalogue attribute. Does the endpoint actually return it? **The onboarding prototype's control decision turns on this and cannot be implemented either way until it is answered.** | `screenshots/registry--default--ar.png` | (a) the onboarding epic — **it changes the endpoint's payload** | | Both review queues and the reference-data screen carry the platform-scope band. It is read once and then it is wallpaper. Is a **per-row** provenance column doing more work than the band? | `screenshots/admin--default--ar--table.png` | (c) a convention | ### The review pattern, for P4 and P6 to copy Whatever D3 answers about the **layout**, these five points are the pattern and do not change between the two variants. P4 and P6 are handed them as written requirements, not as a screenshot to eyeball. 1. **A queue is a list of things waiting on a person**, oldest first, each row carrying who or what it is about, when it arrived and how long it has waited. No count that is not the length of the queue. 2. **A detail carries the evidence**, the thing being decided about, and what the record would become — beside what it is now. 3. **A decision is two buttons and a reason.** Approve needs no reason. **Refuse requires one**, in free text, and the person refused reads it verbatim — the field says so on screen, and the refuse button is disabled until it is filled. 4. **A decided item stays readable** with its decision, its reason, its reviewer and its date. Nothing in a queue is deleted by being decided. 5. **The decision is recorded against a person**, and that name appears in the "last edit by, and when" column for the rest of the record's life. --- # Write-back Three destinations, one section each, filled in after the review. **No requirement id from any parked requirement document may appear anywhere below.** Restate it in the project's own words or drop it. ## (a) New stories — appended Destination epics: the reference-data answers to the **admin reference-data** epic; the claims answers to the **claim a pre-created profile** epic; the club queue to the **club registration and approval** epic; the option-count question to the **registry-driven self-onboarding** epic. ``` - **As a **, I , so that . - Accept: . ``` Two lines, the second indented by two spaces, append-only. ## (b) Notes on existing stories Written after the review, keyed by 1-based position. ## (c) Rules and conventions for the code repository | Glob | Title | Note | | --- | --- | --- | | — | the review pattern | **D3's answer plus the five points above, verbatim.** Every later queue is built from it, and a queue that departs from it is a defect. | | — | administration's internal shape | **D1's answer.** Not a re-opening of "administration is the application shell with an administration group", which is locked. | | — | destructive writes | **D4's answer**, and whether a destructive write with live dependents is refused rather than confirmed. | --- ## Rejected options Filled in after the review. | Option | Why it was rejected | Evidence | | --- | --- | --- | ## A screen the S1 review found missing, built here **The club approval queue** (`clubs.html`). The S1 review recorded that the platform administrator's landing linked to a club queue and that `?queue=claims` rendered the profile-claims queue instead — "review queues" plural in the navigation, singular in the build. It is built here because this prototype owns review queues, and because **it is built from D3's pattern without changing it**, which is the only real evidence that the pattern transfers. ## What P3 found in the inherited decisions Recorded here rather than acted on, because a locked decision is superseded by a new prototype and never edited. 1. **The owning epic's fourth decision was already answered by S1.** The ticket asks "whether admin pages need a distinct visual treatment from customer pages". S1 settled it: the same shell, with the band, the scope named in every global or destructive confirmation, and the "last edit by, and when" column — all three together, and the band alone explicitly not sufficient. P3 does not re-ask it. **D4 is the live remainder**: whether naming the scope is enough for a *destructive* write. If the reviewer wants the original question reopened, that is a new prototype superseding S1, not a decision inside this one. 2. **S1 shipped two administration entries; Stage 2 has five.** That is not a contradiction — S1 had two administration screens — but it is the reason D1 exists, and all five prototypes now render the same five entries so no two disagree about where a screen lives. ## Not settled - A claim approved hands one account another account's record. Nothing here says what happens to a **duplicate profile the claimant may already have created** — whether it is merged, hidden or left standing. - Whether an administrator may edit a registry **group's attributes**, or only the catalogues they draw from. The registry page is read-only here because the prototype had to pick one, and the choice changes what the admin API may write. - Whether a refused club may re-register immediately, and whether its refusal reason follows it if it does. - The **sporting catalogue** — federations, seasons, age categories, tournaments, windows — is reference data of exactly this shape and is built in P4, which owns the screens that consume it. Whether it should have been here instead is worth five minutes of the review. ## Not built Empty at the time of writing.