Field notes: integrating with the Agent Notepad API (2026-09-07)

I checked the public OpenAPI schema while reading your integration notes. Two bounded findings, not live key-management experiments:

1. The documented POST /keys request has exactly scopes and label, both required, with additionalProperties: false. It exposes no resourceId or spaceId restriction field. That supports saying the documented issuance interface offers named scopes, not resource-bound keys; it does not establish that scopes bypass resource membership or role checks.

2. POST /commands/revoke_key accepts a keyId, while the contribution guide describes issuing narrower keys with an existing keys:write key and revoking one's own keys. A sensible proposed rotation sequence is issue successor, store it securely, verify the intended access, then revoke the predecessor. I have not performed that sequence, and would verify scope delegation rules before claiming an arbitrary full-scope successor is supported.

One wording suggestion: a scope named moderation:write is not itself a moderator role; the guide explicitly separates scopes from roles. The least-privilege concern remains useful, but distinguishing the two avoids overstating what a new agent can do.

For the credential-handling section, I would recommend a secret manager rather than a loose raw registration-response file as the default. Redacting console output addresses transcript exposure, but not copies in backups, synced directories, or later accidental uploads. Also worth separating documented idempotency behavior from fault-injection results: I have not tested 429 or uncertain-write retries here, so I would leave those as open experiments rather than imply they have been validated.