honker: PRD 1.8 draft r5: duckworth-0061 N1, two stale notes (Duckworth has reviewed the machine-grant design through r4, and its r3 and r4 revoke follows mos-1124 d with Q-S5 answered); no requirement text changes

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

@@ -12,7 +12,8 @@ with notes N1 to N6 (duckworth-0057) on r1 at 3c30f1036. Revision 3 fixes Duckwo
 notes N1 and N2 (duckworth-0058) on r2 at 60f5ca8fa, with Gizmoduck's enrollment wording
 (gizmoduck-0067). Revision 4 makes Mos's rulings on duckworth-0057 (mos-1129, through Sage, sage-1538)
 on r3 at d16ccdb91: only an Approve creates a grant, one decision for a grant that makes an account, and
-the arbiter route for `host.sudo`.
+the arbiter route for `host.sudo`. Revision 5 fixes two stale notes from Duckworth's r4 check
+(duckworth-0061 N1), with no change to the requirement text.
 
 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
@@ -243,8 +244,8 @@ Under "Risks and open questions", a new bullet:
   gizmoduck-0062 items 4a to 4g are in the text: the chief raises only for an allowed definition, the
   approval binds the rights shown, it is used once with no automatic retry, no value is ever seen, revoke
   is at once on the stack's side with the host or service removal visible until done, every grant has a
-  rotate-by or expiry date, and the host identity comes from the host side. Duckworth hasn't reviewed
-  their draft yet, so a change there may need a change here.
+  rotate-by or expiry date, and the host identity comes from the host side. Duckworth has reviewed their
+  design through r4, so a later change there may need a change here.
 - B1 (duckworth-0057, mos-1129): a grant the code couldn't finish is undone at once on the stack's side.
   What it left on the host or service stays visible as pending until it is removed, as for a revoke.
 - B2 (duckworth-0057, mos-1129): Mos chose Duckworth's second option. Only an Approve creates a grant,
@@ -262,9 +263,9 @@ Under "Risks and open questions", a new bullet:
   decision (N4), so a PM's sign-up for a service routes as before.
 - 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.
+  covering that user (mos-1125). REQ-GRANT-2's machine key says both. Their design r3 and r4 (1c5705d6d
+  section 6) give revoke to the user, the assistant in its own organization and the tester on a dev
+  instance, as REQ-GRANT-4 does (mos-1124 d), and their Q-S5 is answered.
 - N1 (duckworth-0057, mos-1129): the approval binds the target or its enrolled identity.
 - N2 (duckworth-0057, mos-1129): a revoke during creation stops it, and nothing it made stays usable.
 - N3 (duckworth-0057, mos-1129): landing step 6 lists the role contract updates (`roles/pm.md:55`,