honker: PRD 1.8 draft r3: Duckworth's C1 (the chief-only raise and the makes-nothing rule apply only to an account.create that carries a grant method, a PM's service sign-up routes as in 1.7), N1 (a hand-written grant is held to the same bounds at load, rotate-by included), N2 (a revoke never rewrites the user's file); Gizmoduck's enrollment wording (mos-1120, mos-1125) and the Q-S5 revoke note

agents/honker/work/queue-194/PRD-1.8-DRAFT.md

@@ -8,7 +8,9 @@ approved (PRD-1.7-DRAFT.md r2, 9ba31b5b3, decision d52febb5, mos-1089). Where 1.
 the PRD file, this draft's anchors name 1.7's sections.
 
 Revision 2 makes Mos's edits a to f (mos-1124, through Sage, sage-1534) and fixes Duckworth's B1 and B2
-with notes N1 to N6 (duckworth-0057) on r1 at 3c30f1036.
+with notes N1 to N6 (duckworth-0057) on r1 at 3c30f1036. Revision 3 fixes Duckworth's C1 and takes
+notes N1 and N2 (duckworth-0058) on r2 at 60f5ca8fa, with Gizmoduck's enrollment wording
+(gizmoduck-0067).
 
 For Jason at approval: "The main agent or chief of staff" in Q10 is read as one role under two names,
 the chief of staff. So only the chief raises a grant request, and your assistant passes your own request
@@ -53,7 +55,9 @@ When this version lands, reviewed commits:
    any other routing.
 2. add the grant request: a decision the chief of staff raises with action `credential.mint`, or
    `account.create` when the grant makes an account, naming the agent, the method and target, and the
-   exact rights (REQ-GRANT-1). The broker refuses the raise from any other role.
+   exact rights (REQ-GRANT-1). The broker refuses a `credential.mint` raise, and an `account.create`
+   raise that carries a grant method, from any other role. An `account.create` raise with no grant
+   method, such as a PM's sign-up for a service, routes as it does in version 1.7.
 3. add the grant code that runs on a resolved Approve, one method at a time, and the grant record it
    writes (REQ-GRANT-2, Vikunja #435 and #436).
 4. add the user's token store, written from the WebUI (or the CLI until the Console knows the signed-in
@@ -155,7 +159,8 @@ Under "Credentials", after REQ-CRED-3 (version 1.7):
 >   key or token, installs it on the machine or creates it on the service, and logs each step. On Deny
 >   nothing is made, and the denial is logged. The grant methods are:
 >   - machine key: a key for one agent on one enrolled host, with the command allowlist of REQ-CRED-4. A
->     host's identity comes from the host side when the user enrolls it, never from a first connection;
+>     host's identity comes from the host side when the user approves its enrollment, never from a first
+>     connection. A host user with sudo receives a grant only after the user approved that user by name;
 >   - Gitea: a token for one agent, and for an agent seat its own Gitea user (Q190), with an expiry. The
 >     all scope and the admin scope are never granted;
 >   - GitHub: a grant for one agent.
@@ -168,9 +173,12 @@ Under "Credentials", after REQ-CRED-3 (version 1.7):
 >   is never used. What it left on the host or service stays visible as pending until it is removed, as
 >   for a revoke (REQ-GRANT-4). A new grant needs a new approval, never an automatic retry. The grant
 >   code runs only on a request the user resolved. A request resolved by an arbiter, the tester or any
->   agent makes nothing. A `credential.mint` or `account.create` decision raised before version 1.8, or
->   without the fields of REQ-GRANT-1, makes nothing. Until the Console knows the signed-in human (Vikunja
->   #412), Approve is `mosaic decide` in the CLI (REQ-DEC-3).
+>   agent makes nothing. The grant code makes nothing from a `credential.mint` decision raised before
+>   version 1.8 or without the fields of REQ-GRANT-1, or from an `account.create` decision with no grant
+>   method. An `account.create` decision with no grant method isn't a grant request and stays as version
+>   1.7 has it. A grant the user writes by hand is held to the same bounds when it is loaded: a wildcard,
+>   a shell, an empty command or a missing rotate-by date is refused (REQ-CRED-4). Until the Console
+>   knows the signed-in human (Vikunja #412), Approve is `mosaic decide` in the CLI (REQ-DEC-3).
 > - **REQ-GRANT-3.** The user enters their own personal access tokens and API tokens in the WebUI, or the
 >   CLI. Only the grant code reads them, to make grants. No agent ever sees a token value or a key's
 >   private half. Values appear in no event, log, message, prompt or agent file, and no agent can read
@@ -230,6 +238,22 @@ Under "Risks and open questions", a new bullet:
   leave no way to make a new grant between row 210 landing and the grant code (#435, #436) landing. Q188
   calls requiring the user to do the steps a no-fly. This text allows the hand path and requires it
   nowhere. Mos or Jason can close it once the grant code is live.
+- C1 (duckworth-0058): `account.create` is the hard wait for any new external account, not only a grant
+  (REQ-WAIT-1, `vocabulary.mjs:43-46`, `roles/pm.md:55`). So landing step 2 and REQ-GRANT-2 apply the
+  chief-only raise and the "makes nothing" rule only to an `account.create` raise that carries a grant
+  method. A PM's sign-up for a service routes as in version 1.7.
+- N1 (duckworth-0058): a grant the user writes by hand isn't a request, so REQ-GRANT-1's bounds don't
+  reach it as a request. REQ-GRANT-2 has the loader refuse a hand-written grant with a wildcard, a
+  shell, an empty command or no rotate-by date. Row 210's key entry already carries one (`rotateBy`,
+  origin/gizmoduck/row210-on-199-r2 `agents/gizmoduck/work/queue-210/DESIGN.md:144`).
+- Gizmoduck's machine-grant r2 (eb4c756a1, gizmoduck-0067): enrollment is a request the user approves
+  and the stack runs (mos-1120), and a host user with sudo is enrolled by name, the user's Approve
+  covering that user (mos-1125). REQ-GRANT-2's machine key says both. Their design gives revoke to the
+  user and the tester only, and their Q-S5 asks Jason whether the assistant gets it too. REQ-GRANT-4
+  follows Mos's ruling (mos-1124 d) until Jason answers Q-S5, and then matches his answer.
+- N2 (duckworth-0058), for #436: a revoke by the assistant or the tester can reach a grant the user
+  wrote by hand. The revoke marks the grant revoked in the stack's own record and never rewrites the
+  user's business file.
 - N4 (duckworth-0057): a decision carries one action (`a.action`, broker.mjs:1678 on origin/refactor). A
   request that makes an account is raised as `account.create` and names its credential, so the decision
   shape doesn't change.