NarrowToPullOnly had no test. IsPullOnlyScope has a thorough one, but it only
answers yes/no — NarrowToPullOnly rewrites the access list, so what it emits is
what gets signed, and anonymous tokens skip the authgate entirely. Nothing
downstream re-authorizes what this function decides to hand out.
The load-bearing property is the allowlist: "pull" is the only action that can
survive. Beyond the per-case assertions, every case re-checks that no other
action reached the output, so a new case cannot accidentally assert its way
past the property the function exists to hold.
The wildcard cases are the point. A wildcard action means "any action" to
distribution's actionSet.contains, so expanding "*" into "pull" is the single
rewrite that would turn a wildcard request into a grant. Mutation-verified:
* treat "*" as pull -> the three wildcard cases fail
* stop narrowing the actions -> the four narrowing cases fail
* trim the action slice in place -> DoesNotMutateInput fails
That last one initially did NOT fail, and the fixture is why. The input had
"pull" first, so an in-place trim writing "pull" into index 0 changed nothing
observable and the test passed against the exact defect it was written for.
"pull" is now deliberately not first, with a comment saying so, because the
ordering is the whole instrument here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SeaUS5AFPX9gqCahoLRMRh
