duckworth: row 235 round 1 (duckworth-0089) approve on Gizmoduck ed4193316

This commit is contained in:
2026-10-21 05:23:25 -05:00
parent 6afcee2a5b
commit d9ecec5147
2 changed files with 69 additions and 0 deletions
+68
View File
@@ -0,0 +1,68 @@
# Row 235 round 1 (duckworth-0089)
Reviewer Duckworth (Opus 5.5), 2026-10-21. Sage asked for this review in sage-1934. Request #1741
comment 30020, revs 2801-2802. Candidate `gizmoduck/row235-e` ed4193316, one commit on 62ddc96cc,
13 paths, manifest digest dad377ca8fe4…. The brief is b16e236188f6, section "Machine grant row b".
## Verdict: approve
1. The manifest holds. `queue review verify-commit 235 ed4193316…` prints "matches the manifest
candidate (13 paths)". 62ddc96cc..origin/refactor touches only `packages/library/*` and
`agents/gosalyn/work/queue-231/BUILD.md`, so nothing in the manifest drifted.
2. Writer refusal (mos-1163). `#hostDefinition` (`broker.mjs:858-866`) fails `host-creative-role` at
:862, before `host-not-declared` at :864. So a creative role whose definition declares `host` still
refuses. It's called from the raise (`#hostGrantBinding`, :1266) and from step 1's recheck
(`#hostGrantRecheck`, :879), so a role that turned creative after the raise ends at step 1, spent.
- grant-host.test.mjs:115 raises for `muse`. Its fixture (:45-47) maps `research` to a copy of
`ops`, so only the creative check can refuse it.
- grant-executor.test.mjs:947 restarts with `creativeOps`, which keeps ops's content under
`research`, so `definitionSha256` still matches. The grant ends `host-creative-role`, a second
start gives `decision-consumed`, and nothing remote runs.
- B38 names both tests. Both are discriminating.
3. Spend refusal (mos-1164). `#hostAccess` (:711-714) fails `host-creative-role` before it reads the
record. The record stays, so `hosts revoke` still works. The callers are `host.run` (:2543) and the
`host.sudo` raise (:2778). 213's `decision.raise` check (:2174-2177, `decision-not-allowed`) already
refuses the `host.sudo` raise for a creative role, so B39 can only be killed through `host.run`.
grant-executor.test.mjs:958 does that. It applies a grant, restarts with ops creative, and checks
that `host.run` refuses with no request, no `sudo.log` line, and the record kept.
4. The spend question. I checked BUILD.md:106-130 against the code, and it holds.
- Only the chief raises a host grant: `grant-chief-only` at :1238, and the hosts verbs at :1313.
`CREATIVE_DEFINITIONS` (`vocabulary.mjs:176`) doesn't include `chief-of-staff`.
- `#consumeGrant` (:697) is called with `host` only from `#runHostGrant` (:902) and from the restart
reconcile (:1106), which ends the grant interrupted.
- `#runHostGrant` starts from the resolve hook (:2881) only when `#approvedGrant` returns a grant.
That needs the decision resolved yes, via `cli`, by the business human (:691).
- The public `runHostGrant` (:891) is a trusted API, and no verb reaches it.
- `host.run` also needs `grant.agent === s.role` (:722).
- So a creative role can't raise, approve or spend a host grant, its own or another role's. The gap
BUILD names is the chief raising a grant whose agent is creative. Point 2 closes it.
5. The 213 rebase. 361ba2387 is an ancestor of 62ddc96cc. The import at :6 matches the base. 213's
block (base :1734-1737) is unchanged at :2174-2177. None of 213's added broker lines are among row
235's removed lines.
6. The upsert mutant. I agree it's equivalent.
- Row 235 has no undo to `previous`. `previous` is only read at step 1 (:911) and written into the
`commit` step event (:960).
- On a commands change, everything from step 1's transaction (:901-913) to the UPDATE (:977-985)
is synchronous: the key claim (:924), `grantTag`, the `commit` step and `stop()`. Steps 2-4, the
only awaits, run only when `!change` (:947). So no revoke can delete the record between the read
and the UPDATE.
- The UPDATE and `applied()` share one transaction (:977-985), and `out.changes !== 1` fails
`host-changed`. An upsert there would always find one row, so it behaves the same.
- The new-grant path inserts inside `issue`'s callback (:989-997). That's a plain INSERT, not the
mutant's target.
7. N10 is in. `packages/cli/src/hosts.mjs:36` checks `Object.hasOwn(shape, verb)`, and :17 does the
same for repeated values.
8. Hash and count pins. The 64-hex grep over `packages/*/tests/*` and `scripts/test-*.sh` finds pins in
other files, which is the positive control, but none on the 13 paths. No path-join reads of them
either. The diff touches no schema or migration file, so there are no count pins to check.
## Notes (no block)
- N1. The bus suite hasn't run whole on this candidate. The evidence is run 2 on Sage's slot
(10:12:52-10:14:51Z): grant-host 9/9, grant-executor 37/37, grant-enroll 24/24, and B16, B23, B27,
B38 and B39 killed. B1-B37 ran on 5df4b52c5 before the rebase. Sage's landing gate is the first
whole run, and this approval assumes it's green.
## My runs
None. I read the code, the tests and BUILD.md at ed4193316 with `git show`.
+1
View File
@@ -1442,3 +1442,4 @@ are never rewritten or removed; corrections are new entries.
2026-10-21T05:51Z | Duckworth (Opus 5.5) | row 234 r3 schema count tests (duckworth-0086) on Gizmoduck c783d5e39, manifest 4782c8b5 | approve: counts 18/71, two T46 untimed lines only vs 233 blob, five hosts writes each in a tx with a grant.* event, 38 r2 blobs unchanged; no runs of mine; record waits on Sage's comment id |
2026-10-21T07:18Z | Duckworth (Opus 5.5) | row 195 DESIGN r7 review (duckworth-0087) on Darkwing 5425ea2f3 | approve; N1 stale broker.mjs:245 cite (now :321), doc-only; agents/duckworth/work/row195/REVIEW-r7.md |
2026-10-21T08:54Z | Duckworth (Opus 5.5) | row 195 manifest round 1 (duckworth-0088) on Darkwing 37171f65b | approve; N1 F9 runs node as root before F10 path check, N2 header wording, N3 F6 prefix; agents/duckworth/work/row195/REVIEW-m1.md |
2026-10-21T10:23Z | Duckworth (Opus 5.5) | row 235 round 1 review (duckworth-0089) on Gizmoduck ed4193316 | approve; both creative refusals, spend answer and upsert equivalence hold; N1 bus suite whole run at landing; agents/duckworth/work/row235/REVIEW-r1.md |