honker: PRD 1.8 draft r7 takes Mos's r6 rulings (mos-1152, sage-1631): the heading reads "For Jason at approval:" with Mos's reading of the Q188 revokers, the machine-grant citation names r1 to r4, the revoke note drops the Q-S5 claim

2026-10-20 20:15:53 -05:00
parent 47c2cb33c3
commit 82df17347d
1 changed files with 8 additions and 4 deletions
@@ -15,13 +15,17 @@ on r3 at d16ccdb91: only an Approve creates a grant, one decision for a grant th
 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. Revision 7 is on r5 at 762a6711f, not r6
 (Jason, Q191, through Mos mos-1149 and Sage sage-1623): the assistant and the chief of staff are separate
-roles, and only the chief raises a grant request.
+roles, and only the chief raises a grant request. It also takes Mos's rulings on r6 items 1, 3 and 4
+(mos-1152): the heading below reads "For Jason at approval:" again with Mos's reading of the Q188 revokers,
+the machine-grant citation names r1 to r4, and the revoke note no longer says their Q-S5 is answered.

 Only the chief of staff raises a grant request. The assistant, the user's main agent, never raises one.
 It passes the user's request to the chief and can revoke a grant in its own organization.

-Also for Jason at approval:
+For Jason at approval:

+- Q188's 'you, Mos or the tester' is read as the user, the assistant for grants in its own organization, and the
+  tester only on a dev instance (Mos's reading, mos-1124 d).
 - Only an Approve creates a grant. A grant written into the business file by hand makes nothing. An agent
  that runs as the same OS user as the stack can still write the stack's own store. That is the B7
  residual (Q182 on dragon-lin, #423 on .53 and .54), and this version doesn't close it.
@@ -246,7 +250,7 @@ Under "Risks and open questions", a new bullet:
  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 has reviewed their
-  design through r4, so a later change there may need a change here.
+  design r1 to r4 (duckworth-0056 and duckworth-0060), 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,
@@ -266,7 +270,7 @@ Under "Risks and open questions", a new bullet:
  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 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.
+  instance, as REQ-GRANT-4 does (mos-1124 d).
 - 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`,