docs(12.1): create phase plan

.planning/phases/12.1-user-plugin-admin-screens/12.1-RESEARCH.md

@@ -718,33 +718,41 @@ toolbar:
 | A11 | The recommended interface, YAML key and route names | Contract names table | Naming only; cheap before release, costly after v0.1.3 |
 | A12 | Row states limited to `deleted`, `negative`, `disabled` | Row state | A later plugin needs more; adding a state is additive |
 
-## Open Questions
+## Open Questions (RESOLVED)
+
+All six questions were answered by the user at the plan-count checkpoint on 2026-10-04. The answers are locked decisions in `12.1-CONTEXT.md`; each question below names the decision that settles it.
 
 1. **Are the extra framework seams (G1 to G7) accepted into v0.1.3?**
    - What we know: D-07, D-19 and D-22 cannot be met with the five decided features alone; evidence is quoted above.
    - What's unclear: whether the user wants all of them in this phase or prefers to relax a decision (for example an organisation field that stays read-only on the user form and is managed only from the organisation's members tab).
    - Recommendation: present G1 to G7 at the plan-count checkpoint as one table with "needed for D-xx" and let the user accept or cut each.
+   - RESOLVED by D-27: all seven seams (G1 to G7) are accepted into v0.1.3.
 
 2. **How should the admin form's validation rules be supplied (G5)?**
    - What we know: `User.Rules()` is the register contract and cannot change.
    - What's unclear: framework rules interface on the controller versus an admin-only wrapper record type in the plugin.
    - Recommendation: the controller interface. It is a few lines in `mergedRules`, is useful to every plugin whose API and admin rules differ, and avoids the embedded-struct risks in A7.
+   - RESOLVED by D-28: an optional controller interface returns the rule set per operation; no wrapper record type.
 
 3. **Does the User Groups screen get a delete button?**
    - What we know: PHP's group form and list have no delete; D-06 names "deleting a privileged group".
    - Recommendation: keep the standard form delete (any cabana form has one), guard it per D-06, and clean the pivot rows.
+   - RESOLVED by D-29: User Groups keep the standard form delete, guarded per D-06, with pivot cleanup.
 
 4. **`last_seen` write policy.**
    - What we know: PHP only touches it from the CMS session component, at most once per five minutes; the JWT API never does. Go refresh does not load the user.
    - Recommendation: write on login and on refresh, as one `UPDATE users SET last_seen = now() WHERE id = ? AND (last_seen IS NULL OR last_seen < now() - interval '5 minutes')`, errors logged and ignored so auth never fails on it.
+   - RESOLVED by D-29: written on login and on refresh, at most once per five minutes; a failed write never fails auth.
 
 5. **Admin-created users: activated or not?**
    - What we know: in PHP a backend-created user is not activated; with `send_invite` the mail carries a link, without it the admin activates manually from the preview hint.
    - Recommendation: same in Go; `is_activated` stays a protected key and only the `activate` actions set it.
+   - RESOLVED by D-29: a user created in the admin starts not activated; only the `activate` actions set `is_activated`.
 
 6. **Does bulk `activate` on an already activated user fail the whole batch?**
    - What we know: PHP `attemptActivation` throws "User is already active!" mid-loop, leaving earlier rows changed.
    - Recommendation: skip already-active users and report the affected count; record it as a deliberate deviation (the admin API has no PHP contract to match).
+   - RESOLVED by D-29: bulk `activate` skips users that are already active and reports the affected count.
 
 ## Environment Availability