[mgilardi]

Why

An accepted proposal sealed a name the host chose (proposals.nameOf) into the new snapshot, inside its checksum. A name there can't be taken out when a person leaves a site, and a published version may already be pinned and cited.

What changes

• proposals.personId({ req }) gives an opaque id (default: the signed-in user's document id). That id is all a proposal stores about its author, and all an accepted proposal seals for the author and the manager.
• An id is 1 to 64 letters, digits, ., _, : and -, starting with a letter or digit. An email address or a name with a space is refused: the action stops, nothing is saved, and the refused value isn't logged.
• proposals.displayName({ req, personId }) is optional. It is looked up each time a proposal is read (once per person per request) and returned as authorName. It is never stored or sealed.
• proposals.nameOf is removed. The plugin isn't on npm, so nothing released changes.
• Core still seals the strings it is given. Only comments and one error text changed there.
• The example site keeps its handle, shown through displayName.

Tested

• 526 unit tests, 142 of them in the plugin on Payload 3.93 with an in-memory MongoDB.
• The example site's smoke test: 47 checks, on next dev and on the built site.
• Eight deliberate breaks of the new code, one at a time. Each failed a test.

Not tested, and limits

• Postgres or SQLite, and a host with more than one auth collection.
• A one-word handle passes the id pattern. The plugin can't tell it from an id; the README says not to give one.
• A proposal's title, each move's note and the manager's note are sealed as written and aren't screened.
• An accepted proposal keeps its relationship to the user document. No code can change it.

🤖 Generated with Claude Code