docs(rules): find every user type and its actions in a Spec

docs/rules/DEV-125.md

@@ -23,6 +23,15 @@ about what users can do, not how the system works.
    [DEV-180](./DEV-180.md).
 1. Start with `goal:` frontmatter linking the Goal, then an H1 feature name and
    a `## Overview` of what the Goal enables for users.
+1. List every user type in `## User Types`, including operator and administrator
+   types that are not the client's end-users. If a type's account is provisioned
+   outside the product (database seed, manual setup), say so, and say whether
+   the product can create more of them.
+1. Treat the user account as a key concept, not as a separate administration
+   area: creating, listing, granting access to, and removing accounts are
+   actions on it like any other.
+1. Name the permitted user type in every action. An action with an implicit
+   actor cannot be reviewed against what the product actually allows.
 1. Add author-defined `##` sections that describe observable user behavior, not
    internal mechanics.
 1. Include a `## Design` section using the markup in [DEV-350](./DEV-350.md)
@@ -42,12 +51,17 @@ goal: <link to Goal issue>
 (three items; max 160 chars each)
 
 ## User Types
-(list of end-users' types and their short definition; each item max 150 chars)
+(list of every user type and its short definition, operators and
+administrators included; each item max 150 chars. Note any type whose
+account is provisioned outside the product, and whether more can be
+created in the product)
 
 ## Key Concepts
 
-(subsections describing key concepts end-user needs to know about;
-the relevant methods (actions) specific users can use)
+(subsections describing key concepts users need to know about; the
+relevant methods (actions) each permitted user type can use. Include the
+user account itself as a concept, with its create, list, access, and
+remove actions. Name the permitted user types in every action)
 
 ## [Section]
 
@@ -58,5 +72,10 @@ Describe what users can do, not how the system works internally.
 
 - [ ] The Spec is a `docs/specs/` file with `goal:` frontmatter, an H1 name, and
   a `## Overview`
+- [ ] `## User Types` covers every type, operators and administrators included,
+      states how any externally provisioned account comes into existence, and
+      says whether the product can create more of that type
+- [ ] The user account appears in `## Key Concepts` with its own actions
+- [ ] Every action names the user types permitted to perform it
 - [ ] Sections describe user-observable behavior, not internal mechanics
 - [ ] A Goal with a design component includes a `## Design` section per DEV-350