The allowlist entries are documented where an adopter will look

[sameera]

As a first-time adopter, I want the exact permission entry written down, so that I can grant the toolkit permission once for my account instead of being prompted per repository.

Acceptance Criteria

• Given the install documentation, when it is read, then it carries exactly two allowlist entries — one per named toolkit — each in the trailing-wildcard prefix form that covers every verb and argument list with one entry, and each stated as belonging in the account-scoped settings file rather than a repository-local one.
• Given the upgrade notes, when they are read, then they carry the same two entries, byte-identical to the install documentation's.
• Given the install verb's printed output and the documented entries, when they are compared, then the text is the same.
• Given the documentation, when it is read, then it states that Nexus writes no settings file and that adding the entry is the user's action.

Notes

The decision turns on a scope mismatch rather than on convenience. An interactive approval always saves to the repository's local settings file at the git repository root and offers the user no scope choice — so relying on the prompt yields a repository-scoped grant repeated once per repository, while the toolkit installs once per account. The documented account-scoped entry is not the cheap substitute for the prompt; it is the only path that yields a grant matching the install's scope.

Two uncertainties are recorded rather than resolved, because neither changes the decision: the prefix boundary the permission dialog chooses is undocumented, and whether a bare executable name and a pathed invocation match the same rule is undocumented. Both affect only how often a user who ignores the documented entry is prompted.